[julia-users] Re: polynomial terms in formula specification

[Michael Borregaard]

Thanks for responding, both, it is particularly great to get an answer from 
the father of mixed models in R and julia!

I do have to say I find the functionality slightly disappointing, though. I 
had done what was in the suggested solution, but thought of it as an 
unpleasant workaround. Can anyone explain why Julia has chosen such an 
interface? I can think of no cases where it is a feature, and I see it as a 
problem in several ways, e.g. it does not generalize the functionality and 
the data as separate modular entities, which also means that the formula 
does not express the actual relationship modeled. Also, it does not allow a 
model object that can predict on the basis of a single input variable.

I realize the result will be the same, but in my experience julia is also 
concerned with elegance and intuitive specification. I will say I am really 
surprised. Is this just a matter of implementation, so a possible @formula 
macro planned for the future will restore this functionality?

I have no strong feelings about then '1 +' , it will require typing a few 
unneccesary extra characters, but perhaps there is a pedagogical gain from 
requiring people to specify that they want an intercept fitted as well.

Re: [julia-users] Re: polynomial terms in formula specification

[Tamas Papp]

On Mon, Jun 27 2016, Michael Borregaard wrote:

> I have no strong feelings about then '1 +' , it will require typing a few 
> unneccesary extra characters, but perhaps there is a pedagogical gain from 
> requiring people to specify that they want an intercept fitted as well.

I have nothing to say about your other points, but I love the explicit
intercept (1+), and I hope it stays.

Best,

Tamas

Re: [julia-users] Re: Drop element from tuple

[jw3126]

Thanks again Tim!

On Sunday, June 26, 2016 at 1:41:36 PM UTC+2, Tim Holy wrote:
>
> On Saturday, June 25, 2016 6:45:05 AM CDT jw3126 wrote: 
> > @Tim: Thanks for the insights! On my machine slowness starts to kick in 
> at 
> > size 9 already. 
>
> Depends on which version of julia you're running (I'm running a recent 
> julia-0.5-dev). 
>
> > I tried to read the llvm code, but did not really 
> > understand it. It seems however that the machine will not go through N 
> > (out, t) pairs for a tuple of length N? 
>
> The @inline gives LLVM the chance to elide the apparent intermediates: 
> essentially you're describing the computation you want to perform in a way 
> the 
> compiler can understand, but which may or may not reflect the final 
> operations 
> performed by the CPU. Coaching it into taking the opportunity to fully 
> optimize this operation takes a little practice, and unfortunately 
> sometimes 
> involves a little magic (e.g., https://github.com/JuliaLang/julia/issues/ 
> 17126). 
>
> Best, 
> --Tim 
>
>

[julia-users] Re: Tensorflow like dataflow graphs for Julia?

[Kenta Sato]

You may be interested in Merlin.jl: https://github.com/hshindo/Merlin.jl. 
This supports describing computation graphs in Julia and optimization.

On Saturday, June 25, 2016 at 8:27:31 AM UTC+9, Gabriel Goh wrote:
>
> I'm wondering if a library in Julia exists where I can specify dataflow 
> graphs which can be compiled and differenciated, similar to what tensorflow 
> does. Thanks a lot!
>

[julia-users] Why a Gödelian?

[Stirling Newberry]

 

“No general method for the solution of questions in the theory of 
probabilities can be established which does not explicitly recognize, not 
only the special numerical bases of the science, but also those universal 
laws of thought which are the basis of all reasoning, and which, whatever 
they may be as to their essence, are at least mathematical as to their form." 
Boole


This is a short paper on infinities, plural, and why we should have a 
proper, and properly formed, instance in Julia. The paper divides into 3 
sections:


1) Introduction 

2) The state of the art – and why should do better –

3) A proposal



*1 – Introduction*

While there is a long history, going back At least as far as the 
Antikythera mechanism, a short introduction which will skip over Galileo, 
Pascal, and Newton – while important historically they are not important to 
the thrust of this paper. But what is important is the work of Whitehead 
and Russell. In three papers published 1910, 1912, and 1913 with an amended 
text in 1927 proved, so the thought, that all infinities resolved to a pair 
of true/false assertions. However in 1931 and obscure dissertation was 
published by Gödel which showed that in any system that would allow for a 
sufficiently mathematically complex structure, which he decided to call PM, 
would not resolve. And in fact if it were consistent it could not be 
complete, and if the consistency of the axioms cannot be proved within the 
system that created them. Which has led to a computer bully innumerable set 
of axioms of finite number of sets either 

1. Finite,

2. or it will have a principal which will lead to a third state, with a 
limited number of axioms,

3. or it will be infinite. 

The problem is twofold: the finite systems disallow certain mathematical 
concepts which we need to do adequate work. Multiplication and division are 
two such sets. And for those PM which are in the second state, numbers are 
close at hand. For example, real numbers could be either the second level 
of infinity, or they could be more. This means that in any computable 
universe, as stated by Turing, some equations will not terminate.

This is not in dispute, and can be looked up in variety of mathematical 
textbooks. 

Now for a practically computable system there are workarounds, and as we 
push the limits of the practically computable, the result will break and we 
have to fix it. It is the position of this paper that that time is an 
extended now, and that the previous definition is inadequate.



*2 – The State of the Art*

The State of the Art is actually very smooth from here. Codd and Date 
formed a new theory of NULL and why it should be included in a database. 
This influenced both IBM, and what would eventually be called Oracle. Thus 
SQL has a NULL value in any particular row. Codd and date were specifically 
influenced by Gödel and the logicians who came after him. But the null 
field was inadequate, and they tried to make improvements to it, but none 
of these have caught on. This leads one to the conclusion that there must 
be a Nash equilibrium which turns out to be the first move.

This should be a lesson for all new programming languages – the original 
default of anything is the most likely default. This is why we cannot wait 
on this issue, because if it is not decided – it will be decided by 
default. But is that the right decision?

This cannot known exactly, because of the nature of the problem – but one 
can say if it is better than the least worst version of the problem. In 
this case, the answer is that the least worst is SQL, which has an almost 
Gödelian operator involved with every number and string in its basic 
structure. Since the Julia language is worse than SQL, and therefore 
implies that the Julia language cannot actually control SQL. Since 
commending SQL is in the concept of the language, it is there for not the 
best possible version of the language, by its own definition. 

Moreover, there are at least two problems which will have too be decided in 
the probable lifespan of Julia: one is an old problem, the Zeta function, 
and the other is quite new – the definition of the continuum hypothesis. 
Since these problems are greater than the scope of this paper, future 
papers will be needed to explain them.

But in closing, the data function of Julia is not sufficient for the net 
total language, and must be better than the SQL standard. This standard has 
to involve an array of Gödelians, such that any program can adequately 
explain the level of postulates which will be sufficient to explain the 
logical structure. This will mean not only that it has a Gödelian, but an 
array of them, such that the bottom level will explain why it is not going 
farther. 

This leads us to a structure which has been explained, partially, but not 
fully. In the world of Gödelians, there are three basic features which stop 
a language from going farther: a mathematical basis, a physical basis, an

[julia-users] Row/column iterators?

[Tom Breloff]

I find myself frequently wanting to do something like:

mat = rand(100,4)
for c in columns(mat)
# c is a vector (a view maybe?)
end

I think ideally this method would return a lazy iterator which returns a
`view(mat, :, i)` at each step.  Does this exist already?  If not, would it
be welcomed in Base?

-Tom

[julia-users] Row/column iterators?

[Kristoffer Carlsson]

https://github.com/JuliaLang/julia/issues/14491

Re: [julia-users] Oracle ODBC

[Stefan Karpinski]

Given how expensive Oracle databases are, creating a direct driver isn't
really a plausible open source endeavor, so this is unlikely to happen
unless someone who actually has an Oracle database builds it themselves or
pays for it to be built (e.g. through Julia Computing
).

On Sun, Jun 26, 2016 at 8:51 PM, John Kim  wrote:

> In R, there are direct Oracle OCI drivers.  According to the oracle
> benchmarks, they are 3x faster than the ODBC versions.  Any idea if direct
> OCI will be supported for Julia?
>
>
> On Monday, May 9, 2016 at 1:03:25 AM UTC-7, Stefan Karpinski wrote:
>>
>> You have to install ODBC drivers yourself – the Julia package just
>> provides an interface to them.
>>
>> On Mon, May 9, 2016 at 5:27 AM, John Kim  wrote:
>>
>>> Hello
>>>
>>> I'm new to Julia and would like to start using it for various projects.
>>> One such project requires me to access an Oracle database.  when using the
>>> ODBC package, the listdrivers() command only shows PostgreSQL and MySQL
>>> drivers installed by default.  Are Oracle drivers available for Julia?
>>>
>>
>>

Re: [julia-users] Row/column iterators?

[Tom Breloff]

Thanks for the link!  I'll continue the discussion there.

On Mon, Jun 27, 2016 at 10:06 AM, Kristoffer Carlsson  wrote:

> https://github.com/JuliaLang/julia/issues/14491

[julia-users] Re: [ANN] Measurements.jl v0.1.1: Error propagation library

[Mosè Giordano]

Hi,

2016-06-27 4:32 GMT+02:00 g:
>
> Hello,
> This looks very nice. I will use it next time I have a need. 
>

Thank you :-)
 

> I took a brief look at the code, and I have one question. Why did you 
> choose to "tag" your Measurement types with a random Float64, instead of an 
> incrementing integer?
>

How would you do it?  With a global variable?  I didn't benchmark it, but 
I'm worried about performances.  In addition, this causes a race condition 
when parallelization is enabled, doesn't it?

Bye,
Mosè

Re: [julia-users] Row/column iterators?

[Tim Holy]

In Base there's mapslices, which may already do what you want.

Something like what you're proposing (but not yet with a nice "high level" API 
wrapper, since the low-level stuff is still in flux) is already here:
https://github.com/timholy/ArrayIteration.jl
That's aiming at a very general approach that should be efficient for a wide 
variety of AbstractArrays (dense, sparse, perhaps even distributed, etc). I 
bet you don't need so much generality?

Assuming you'd be happy with something that works well for just dense 
matrices, your `view(mat, :, i)` idea should work just fine. Given that 
julia-0.5 is just around the corner, my assumption is that it would be best to 
put it in a package first, and think about adding to Base later. (But I'm not 
opposed to sticking it in now, either.)

Best,
--Tim

On Monday, June 27, 2016 9:42:33 AM CDT Tom Breloff wrote:
> I find myself frequently wanting to do something like:
> 
> mat = rand(100,4)
> for c in columns(mat)
> # c is a vector (a view maybe?)
> end
> 
> I think ideally this method would return a lazy iterator which returns a
> `view(mat, :, i)` at each step.  Does this exist already?  If not, would it
> be welcomed in Base?
> 
> -Tom

Re: [julia-users] Row/column iterators?

[Tom Breloff]

Thanks Tim!  I can always count on you to have solutions for everything :)

On Mon, Jun 27, 2016 at 11:31 AM, Tim Holy  wrote:

> In Base there's mapslices, which may already do what you want.
>
> Something like what you're proposing (but not yet with a nice "high level"
> API
> wrapper, since the low-level stuff is still in flux) is already here:
> https://github.com/timholy/ArrayIteration.jl
> That's aiming at a very general approach that should be efficient for a
> wide
> variety of AbstractArrays (dense, sparse, perhaps even distributed, etc). I
> bet you don't need so much generality?
>
> Assuming you'd be happy with something that works well for just dense
> matrices, your `view(mat, :, i)` idea should work just fine. Given that
> julia-0.5 is just around the corner, my assumption is that it would be
> best to
> put it in a package first, and think about adding to Base later. (But I'm
> not
> opposed to sticking it in now, either.)
>
> Best,
> --Tim
>
> On Monday, June 27, 2016 9:42:33 AM CDT Tom Breloff wrote:
> > I find myself frequently wanting to do something like:
> >
> > mat = rand(100,4)
> > for c in columns(mat)
> > # c is a vector (a view maybe?)
> > end
> >
> > I think ideally this method would return a lazy iterator which returns a
> > `view(mat, :, i)` at each step.  Does this exist already?  If not, would
> it
> > be welcomed in Base?
> >
> > -Tom
>
>
>

Re: [julia-users] complex int ? A gcc-ism?

[Victor Eijkhout]

Issue submitted.

https://github.com/JuliaLang/julia/issues/17145

V.

[julia-users] using in try catch block

[David Anthoff]

I'm trying to use ``using`` in a try catch block, but that doesn't seem to
be supported.

 

Any other way around this? Essentially I want to load a package, and if the
package is not installed, automatically do a ``Pkg.add``.

 

I could of course get a list of all the installed packages and see if the
one I need is there, but given the slowness of the package manager, I would
prefer to just try to load it first, and only if that fails attempt to
``Pkg.add``.

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

Re: [julia-users] using in try catch block

[Tom Breloff]

Here is what I use for this sort of logic:

function is_installed(pkgstr::AbstractString)
try
Pkg.installed(pkgstr) === nothing ? false: true
catch
false
end
end


On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff 
wrote:

> I’m trying to use ``using`` in a try catch block, but that doesn’t seem to
> be supported.
>
>
>
> Any other way around this? Essentially I want to load a package, and if
> the package is not installed, automatically do a ``Pkg.add``.
>
>
>
> I could of course get a list of all the installed packages and see if the
> one I need is there, but given the slowness of the package manager, I would
> prefer to just try to load it first, and only if that fails attempt to
> ``Pkg.add``.
>
>
>
> Thanks,
>
> David
>
>
>
> --
>
> David Anthoff
>
> University of California, Berkeley
>
>
>
> http://www.david-anthoff.com
>
>
>

Re: [julia-users] using in try catch block

[Yichao Yu]

On Jun 27, 2016 12:20 PM, "Tom Breloff"  wrote:
>
> Here is what I use for this sort of logic:
>
> function is_installed(pkgstr::AbstractString)
> try
> Pkg.installed(pkgstr) === nothing ? false: true

Dont do this since this will miss package in load path. Just eval a using
expression.

> catch
> false
> end
> end
>
>
> On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff 
wrote:
>>
>> I’m trying to use ``using`` in a try catch block, but that doesn’t seem
to be supported.
>>
>>
>>
>> Any other way around this? Essentially I want to load a package, and if
the package is not installed, automatically do a ``Pkg.add``.
>>
>>
>>
>> I could of course get a list of all the installed packages and see if
the one I need is there, but given the slowness of the package manager, I
would prefer to just try to load it first, and only if that fails attempt
to ``Pkg.add``.
>>
>>
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> --
>>
>> David Anthoff
>>
>> University of California, Berkeley
>>
>>
>>
>> http://www.david-anthoff.com
>>
>>
>
>

RE: [julia-users] using in try catch block

[David Anthoff]

Perfect, that is exactly the kind of thing I was looking for! Thanks, David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Yichao Yu
Sent: Monday, June 27, 2016 9:49 AM
To: Julia Users 
Subject: Re: [julia-users] using in try catch block

 


On Jun 27, 2016 12:20 PM, "Tom Breloff" mailto:t...@breloff.com> > wrote:
>
> Here is what I use for this sort of logic:
>
> function is_installed(pkgstr::AbstractString)
> try
> Pkg.installed(pkgstr) === nothing ? false: true

Dont do this since this will miss package in load path. Just eval a using 
expression.

> catch
> false
> end
> end
>
>
> On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff   > wrote:
>>
>> I’m trying to use ``using`` in a try catch block, but that doesn’t seem to 
>> be supported.
>>
>>  
>>
>> Any other way around this? Essentially I want to load a package, and if the 
>> package is not installed, automatically do a ``Pkg.add``.
>>
>>  
>>
>> I could of course get a list of all the installed packages and see if the 
>> one I need is there, but given the slowness of the package manager, I would 
>> prefer to just try to load it first, and only if that fails attempt to 
>> ``Pkg.add``.
>>
>>  
>>
>> Thanks,
>>
>> David
>>
>>  
>>
>> --
>>
>> David Anthoff
>>
>> University of California, Berkeley
>>
>>  
>>
>> http://www.david-anthoff.com
>>
>>  
>
>

Re: [julia-users] using in try catch block

[Tom Breloff]

Yichao: is there an alternative "is_installed" definition that would check
the load path?  Lets assume I don't actually want to import it, just check.

On Mon, Jun 27, 2016 at 12:48 PM, Yichao Yu  wrote:

>
> On Jun 27, 2016 12:20 PM, "Tom Breloff"  wrote:
> >
> > Here is what I use for this sort of logic:
> >
> > function is_installed(pkgstr::AbstractString)
> > try
> > Pkg.installed(pkgstr) === nothing ? false: true
>
> Dont do this since this will miss package in load path. Just eval a using
> expression.
>
> > catch
> > false
> > end
> > end
> >
> >
> > On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff 
> wrote:
> >>
> >> I’m trying to use ``using`` in a try catch block, but that doesn’t seem
> to be supported.
> >>
> >>
> >>
> >> Any other way around this? Essentially I want to load a package, and if
> the package is not installed, automatically do a ``Pkg.add``.
> >>
> >>
> >>
> >> I could of course get a list of all the installed packages and see if
> the one I need is there, but given the slowness of the package manager, I
> would prefer to just try to load it first, and only if that fails attempt
> to ``Pkg.add``.
> >>
> >>
> >>
> >> Thanks,
> >>
> >> David
> >>
> >>
> >>
> >> --
> >>
> >> David Anthoff
> >>
> >> University of California, Berkeley
> >>
> >>
> >>
> >> http://www.david-anthoff.com
> >>
> >>
> >
> >
>

Re: [julia-users] using in try catch block

[Yichao Yu]

On Jun 27, 2016 12:58 PM, "Tom Breloff"  wrote:
>
> Yichao: is there an alternative "is_installed" definition that would
check the load path?  Lets assume I don't actually want to import it, just
check.

No.

>
> On Mon, Jun 27, 2016 at 12:48 PM, Yichao Yu  wrote:
>>
>>
>> On Jun 27, 2016 12:20 PM, "Tom Breloff"  wrote:
>> >
>> > Here is what I use for this sort of logic:
>> >
>> > function is_installed(pkgstr::AbstractString)
>> > try
>> > Pkg.installed(pkgstr) === nothing ? false: true
>>
>> Dont do this since this will miss package in load path. Just eval a
using expression.
>>
>> > catch
>> > false
>> > end
>> > end
>> >
>> >
>> > On Mon, Jun 27, 2016 at 12:12 PM, David Anthoff 
wrote:
>> >>
>> >> I’m trying to use ``using`` in a try catch block, but that doesn’t
seem to be supported.
>> >>
>> >>
>> >>
>> >> Any other way around this? Essentially I want to load a package, and
if the package is not installed, automatically do a ``Pkg.add``.
>> >>
>> >>
>> >>
>> >> I could of course get a list of all the installed packages and see if
the one I need is there, but given the slowness of the package manager, I
would prefer to just try to load it first, and only if that fails attempt
to ``Pkg.add``.
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> David
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> David Anthoff
>> >>
>> >> University of California, Berkeley
>> >>
>> >>
>> >>
>> >> http://www.david-anthoff.com
>> >>
>> >>
>> >
>> >
>
>

[julia-users] Multiple JULIA_PKGDIR directories in a hierarchy for supporting a shared environment

[David Parks]

I want to set up a specific Julia environment on a cluster for other people 
to use. I have particular packages, including some that are dev branches, 
and even some that draw from my own fork of a branch to support a custom 
feature for this environment. So the package setup is non trivial and I 
don't want everyone else to have to follow the details.

Is there a way (now or in the future) to have a hierarchy of package 
directories, so I could have a main repository that I setup and control for 
the relevant packages, but still allow users to extend on that but into 
their own package directory?

Or is there a way good way for me to auto-configure a complex package 
directory for the user? I suppose the obvious answer is to just write a 
package setup script, which might be a suitable solution. But I wonder if 
anything else is possible or on the horizon.

Thanks,
David

Re: [julia-users] Oracle ODBC

[Jacob Quinn]

It's probably the case that Oracle has built the drivers themselves, so a
programming language would just need a wrapper library around the direct
driver (similar things exist for MySQL, Postgres, etc.).

But what Stefan said still applies, someone would have to take the
initiative to build the wrapper library around the Oracle driver and
provide a Julia package. Probably not a terribly hard project (basically
lots of ccalls and some julia-level interface design), but where ODBC
provides a connection more-or-less out of the box, it cuts down a little on
the pressing need.

-Jacob

On Mon, Jun 27, 2016 at 10:23 AM, Stefan Karpinski 
wrote:

> Given how expensive Oracle databases are, creating a direct driver isn't
> really a plausible open source endeavor, so this is unlikely to happen
> unless someone who actually has an Oracle database builds it themselves or
> pays for it to be built (e.g. through Julia Computing
> ).
>
> On Sun, Jun 26, 2016 at 8:51 PM, John Kim  wrote:
>
>> In R, there are direct Oracle OCI drivers.  According to the oracle
>> benchmarks, they are 3x faster than the ODBC versions.  Any idea if direct
>> OCI will be supported for Julia?
>>
>>
>> On Monday, May 9, 2016 at 1:03:25 AM UTC-7, Stefan Karpinski wrote:
>>>
>>> You have to install ODBC drivers yourself – the Julia package just
>>> provides an interface to them.
>>>
>>> On Mon, May 9, 2016 at 5:27 AM, John Kim  wrote:
>>>
 Hello

 I'm new to Julia and would like to start using it for various
 projects.  One such project requires me to access an Oracle database.  when
 using the ODBC package, the listdrivers() command only shows PostgreSQL and
 MySQL drivers installed by default.  Are Oracle drivers available for
 Julia?

>>>
>>>
>

Re: [julia-users] using in try catch block

[Cameron McBride]

On Mon, Jun 27, 2016 at 1:02 PM, Yichao Yu  wrote:
>
> On Jun 27, 2016 12:58 PM, "Tom Breloff"  wrote:
> >
> > Yichao: is there an alternative "is_installed" definition that would
check the load path?  Lets assume I don't actually want to import it, just
check.
>
> No.

Seems like potentially useful function for Pkg module?

Pkg.is_installed(pkgstr)

Or perhaps more useful: is_missing(...)

Although just having several Pkg.add(...) statements for a "setup" step
also seems reasonable.

Cameron

Re: [julia-users] using in try catch block

[Yichao Yu]

On Mon, Jun 27, 2016 at 1:43 PM, Cameron McBride
 wrote:
>
>
> On Mon, Jun 27, 2016 at 1:02 PM, Yichao Yu  wrote:
>>
>> On Jun 27, 2016 12:58 PM, "Tom Breloff"  wrote:
>> >
>> > Yichao: is there an alternative "is_installed" definition that would
>> > check the load path?  Lets assume I don't actually want to import it, just
>> > check.
>>
>> No.
>
> Seems like potentially useful function for Pkg module?

https://github.com/JuliaLang/julia/issues/8679

>
> Pkg.is_installed(pkgstr)
>
> Or perhaps more useful: is_missing(...)
>
> Although just having several Pkg.add(...) statements for a "setup" step also
> seems reasonable.
>
> Cameron

Re: [julia-users] Multiple JULIA_PKGDIR directories in a hierarchy for supporting a shared environment

[Stefan Karpinski]

You can use LOAD_PATH to look in a stack of directories, and you can even
set ENV["JULIA_PKGDIR"] to change which one Pkg manages, but you cannot
manage more than one of them at the same time, since it's unclear what this
would even do.

On Mon, Jun 27, 2016 at 1:28 PM, David Parks  wrote:

> I want to set up a specific Julia environment on a cluster for other
> people to use. I have particular packages, including some that are dev
> branches, and even some that draw from my own fork of a branch to support a
> custom feature for this environment. So the package setup is non trivial
> and I don't want everyone else to have to follow the details.
>
> Is there a way (now or in the future) to have a hierarchy of package
> directories, so I could have a main repository that I setup and control for
> the relevant packages, but still allow users to extend on that but into
> their own package directory?
>
> Or is there a way good way for me to auto-configure a complex package
> directory for the user? I suppose the obvious answer is to just write a
> package setup script, which might be a suitable solution. But I wonder if
> anything else is possible or on the horizon.
>
> Thanks,
> David
>
>

Re: [julia-users] jl_tuple2

[Stephen Chisholm]

Yichao, could you explain why this is unsafe? Do you know of an alternative 
which is safe?

On Monday, 20 June 2016 16:31:29 UTC-3, Yichao Yu wrote:
>
> On Mon, Jun 20, 2016 at 3:27 PM, Stephen Chisholm  > wrote: 
> > While helping out with 
> > 
> http://stackoverflow.com/questions/37913625/call-julia-svd-from-c/37929076#37929076
>  
> > I noticed jl_tuple2 was removed in 
> afd4eb038dcd9fa3e512509f4c332a9e7763ba59 
> > by Jeff Bezanson while refactoring tuples.  Just wondering if anyone is 
> able 
> > to help me find an alternative.  Below is what I used to be able to do. 
>  My 
> > current work around is to use jl_eval_string("(2,2)"), but I'm hoping 
> that 
> > there is still a way to build the dims parameter without a call to 
> > jl_eval_string. 
> > 
> > 
> >   double m[] = {1,2,3,4}; 
> > 
> >   jl_value_t *array_type = jl_apply_array_type(jl_float64_type, 2); 
> >   jl_tuple_t *dims = jl_tuple2(jl_box_int64(2), jl_box_int64(2)); 
>
> FYI, this is generally unsafe. 
>
> >   jl_array_t *jl_m = jl_ptr_to_array(array_type, m, dims, 0); 
> > 
> > 
>

Re: [julia-users] Multiple JULIA_PKGDIR directories in a hierarchy for supporting a shared environment

[Tom Breloff]

Well presumably it could do something that the import logic already does,
but I appreciate that it is complex logic.

David: @wildart is the person to follow for the future of package
management.

On Mon, Jun 27, 2016 at 2:02 PM, Stefan Karpinski 
wrote:

> You can use LOAD_PATH to look in a stack of directories, and you can even
> set ENV["JULIA_PKGDIR"] to change which one Pkg manages, but you cannot
> manage more than one of them at the same time, since it's unclear what this
> would even do.
>
> On Mon, Jun 27, 2016 at 1:28 PM, David Parks 
> wrote:
>
>> I want to set up a specific Julia environment on a cluster for other
>> people to use. I have particular packages, including some that are dev
>> branches, and even some that draw from my own fork of a branch to support a
>> custom feature for this environment. So the package setup is non trivial
>> and I don't want everyone else to have to follow the details.
>>
>> Is there a way (now or in the future) to have a hierarchy of package
>> directories, so I could have a main repository that I setup and control for
>> the relevant packages, but still allow users to extend on that but into
>> their own package directory?
>>
>> Or is there a way good way for me to auto-configure a complex package
>> directory for the user? I suppose the obvious answer is to just write a
>> package setup script, which might be a suitable solution. But I wonder if
>> anything else is possible or on the horizon.
>>
>> Thanks,
>> David
>>
>>
>

Re: [julia-users] Plots with Plots

[Tom Breloff]

For anyone interested, I made a short demo of what's possible with the
GLVisualize backend in Plots, after hacking at JuliaCon with Simon.  Plots,
Interact, and GLVisualize... oh my!

https://www.youtube.com/watch?v=mRvUhLpUq88

I just tagged a new version of Plots... until it's merged you'll need to be
on master or dev.  We're not quite ready for bug reports on GLVisualize...
plenty of things on Simon's todo list :D

On Sat, Jun 25, 2016 at 9:19 AM, daycaster  wrote:

> Plots.jl looks amazing!
>
> A couple of questions:
> Is there any way to control the fonts used in a plot? I can't see any
> obvious way to specify fonts outside the usual range of
> "Helvetica"/"Courier".
>
> Also, I can't get any results from searching the docs. Is search currently
> broken or are there ways to specify words that I don't know?

[julia-users] ERROR: LoadError: __precompile__(true) but require failed to create a precompiled cache file

[Uwe Fechner]

Hello, 

I get the following error message after upgrading Compat.jl (I had it fixed 
before):

julia> include("Plotting.jl")
INFO: Recompiling stale cache file 
/home/ufechner/.julia/lib/v0.4/FixedPointNumbers.ji for module 
FixedPointNumbers.
WARNING: Module Compat uuid did not match cache file
  This is likely because module Compat does not support  precompilation but 
is imported by a module that does.
WARNING: deserialization checks failed while attempting to load cache from 
/home/ufechner/.julia/lib/v0.4/FixedPointNumbers.ji
INFO: Precompiling module FixedPointNumbers...
INFO: Recompiling stale cache file 
/home/ufechner/.julia/lib/v0.4/FixedPointNumbers.ji for module 
FixedPointNumbers.
WARNING: Module Compat uuid did not match cache file
  This is likely because module Compat does not support  precompilation but 
is imported by a module that does.
ERROR: LoadError: __precompile__(true) but require failed to create a 
precompiled cache file
 in require at ./loading.jl:268
 in stale_cachefile at loading.jl:457
 in recompile_stale at loading.jl:474
 in _require_from_serialized at loading.jl:83
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:235
 in stale_cachefile at loading.jl:457
 in recompile_stale at loading.jl:474
 in _require_from_serialized at loading.jl:83
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:235
 in stale_cachefile at loading.jl:457
 in recompile_stale at loading.jl:474
 in _require_from_serialized at loading.jl:83
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:235
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:320
while loading /mnt/ssd/ufechner/00PythonSoftware/FastSim/src/Plotting.jl, 
in expression starting on line 21

julia> 

Any idea, how to fix this?

Uwe Fechner

[julia-users] Julia 0.4.6 MD5's are not Matching...

['Danny Hunt' via julia-users]

Julia Support,

Thanks for this awesome language!

Twice today I have downloaded the latest Julia version 0.4.6 and checked 
the MD5 against the posted hash and they are not matching, the previous 
released did.  As a backup I checked with a second checker and checked 
SHA256 as well.  All checksums are negative.

Thanks in advance,
Danny K. Hunt

[julia-users] Re: Julia 0.4.6 MD5's are not Matching...

[Tony Kelman]

My mistake. Automated code signing of the Windows binaries has been 
problematic for the last several months, so I've had to do it manually. The 
code signing happened after downloading the unsigned binaries and 
calculating their checksums, so just a mistake in the order these ran in 
since codesigning on Windows changes the file contents. I'll re-upload new 
checksum files shortly.


On Monday, June 27, 2016 at 4:35:13 PM UTC-4, Danny Hunt wrote:
>
> Julia Support,
>
> Thanks for this awesome language!
>
> Twice today I have downloaded the latest Julia version 0.4.6 and checked 
> the MD5 against the posted hash and they are not matching, the previous 
> released did.  As a backup I checked with a second checker and checked 
> SHA256 as well.  All checksums are negative.
>
> Thanks in advance,
> Danny K. Hunt
>
>

Re: [julia-users] Re: polynomial terms in formula specification

[Michael Krabbe Borregaard]

And... Sorry if I sounded unnecessarily critical, I just hoped to argue the
case for a change. I know all decisions in Julia are based on careful
consideration of all the options.

[julia-users] Re: Julia 0.4.6 MD5's are not Matching...

['Danny Hunt' via julia-users]

All better now, thanks!

On Monday, June 27, 2016 at 5:34:54 PM UTC-4, Tony Kelman wrote:
>
> My mistake. Automated code signing of the Windows binaries has been 
> problematic for the last several months, so I've had to do it manually. The 
> code signing happened after downloading the unsigned binaries and 
> calculating their checksums, so just a mistake in the order these ran in 
> since codesigning on Windows changes the file contents. I'll re-upload new 
> checksum files shortly.
>
>
> On Monday, June 27, 2016 at 4:35:13 PM UTC-4, Danny Hunt wrote:
>>
>> Julia Support,
>>
>> Thanks for this awesome language!
>>
>> Twice today I have downloaded the latest Julia version 0.4.6 and checked 
>> the MD5 against the posted hash and they are not matching, the previous 
>> released did.  As a backup I checked with a second checker and checked 
>> SHA256 as well.  All checksums are negative.
>>
>> Thanks in advance,
>> Danny K. Hunt
>>
>>

Re: [julia-users] Re: polynomial terms in formula specification

[dnm]

I think the formula interface is slated to get an overhaul..but someone can 
correct me if I'm wrong. 

On Monday, June 27, 2016 at 5:49:18 PM UTC-4, Michael Borregaard wrote:
>
> And... Sorry if I sounded unnecessarily critical, I just hoped to argue 
> the case for a change. I know all decisions in Julia are based on careful 
> consideration of all the options. 
>

[julia-users] Any examples of using Julia with online judge systems

[Андрей Логунов]

Are there any projects/initiatives to apply Julia with online judge systems 
(https://en.wikipedia.org/wiki/Online_judge) like spoj, codechef, 
codeforces for use in education

[julia-users] Re: Multiple JULIA_PKGDIR directories in a hierarchy for supporting a shared environment

[Eric Forgy]

Hi David,

I'm not a pro, but I had similar issues and went with a main Julia package 
that contains many other Julia packages as Git submodules. In this way, my 
team can just clone the main Julia package and do a "git submodule init" 
and "git submodule update" and they get all the packages from the main 
Julia package. Then I added two lines to my .juliarc.jl file that add the 
Git submodule directory to my LOAD_PATH. Now my team can add any packages 
they like but are assured to have the same packages (and versions) for the 
main Julia package.

Best regards,
Eric

On Tuesday, June 28, 2016 at 1:28:25 AM UTC+8, David Parks wrote:
>
> I want to set up a specific Julia environment on a cluster for other 
> people to use. I have particular packages, including some that are dev 
> branches, and even some that draw from my own fork of a branch to support a 
> custom feature for this environment. So the package setup is non trivial 
> and I don't want everyone else to have to follow the details.
>
> Is there a way (now or in the future) to have a hierarchy of package 
> directories, so I could have a main repository that I setup and control for 
> the relevant packages, but still allow users to extend on that but into 
> their own package directory?
>
> Or is there a way good way for me to auto-configure a complex package 
> directory for the user? I suppose the obvious answer is to just write a 
> package setup script, which might be a suitable solution. But I wonder if 
> anything else is possible or on the horizon.
>
> Thanks,
> David
>
>

Re: [julia-users] Oracle ODBC

[cdm]

extending the wrapper theme ...

do survey: 
  
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html



On Monday, June 27, 2016 at 10:30:14 AM UTC-7, Jacob Quinn wrote:
>
> It's probably the case that Oracle has built the drivers themselves, so a 
> programming language would just need a wrapper library around the direct 
> driver (similar things exist for MySQL, Postgres, etc.).
>
> But what Stefan said still applies, someone would have to take the 
> initiative to build the wrapper library around the Oracle driver and 
> provide a Julia package. Probably not a terribly hard project (basically 
> lots of ccalls and some julia-level interface design), but where ODBC 
> provides a connection more-or-less out of the box, it cuts down a little on 
> the pressing need.
>
> -Jacob
>