[julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

JuliaPraxis is on  github  and gitter 
 ... bring our praxes. 


On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I have created a new Organization on github: *JuliaPraxis.*
> Everyone who has added to this thread will get an invitation to join, and 
> so contribute.
> I will set up the site and let you know how do include your wor(l)d views.
>
> Anyone else is welcome to post to this thread, and I will send an 
> invitation.
>
>
>
> On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote:
>>
>> Conventions would have to be arrived at before this is possible.
>>
>> On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote:
>>>
>>> In my opinion the solutions to this are very clear, or would be:
>>>
>>> 1. make a mandatory linter for all julia code
>>> 2. julia IDEs should offer good intellisense
>>>
>>> Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:

 Something that I have been noticing, as I convert more of my research 
 code over to Julia, is how the super easy to use package manager (which I 
 love), coupled with the talent base of the Julia community seems to have a 
 detrimental effect on the API consistency of the many “micro” packages 
 that 
 cover what I would consider the de-facto standard library.

 What I mean is that whereas a commercial package like 
 Matlab/Mathematica etc., being written under one large umbrella, will 
 largely (clearly not always) choose consistent names for similar API 
 keyword arguments, and have similar calling conventions for master 
 function 
 like tools (`optimize` versus `lbfgs`, etc), which I am starting to 
 realize 
 is one of the great selling points of these packages as an end user. I can 
 usually guess what a keyword will be in Mathematica, whereas even after a 
 year of using Julia almost exclusively I find I have to look at the 
 documentation (or the source code depending on the documentation ...) to 
 figure out the keyword names in many common packages.

 Similarly, in my experience with open source tools, due to the 
 complexity of the package management, we get large “batteries included” 
 distributions that cover a lot of the standard stuff for doing science, 
 like python’s numpy + scipy combination. Whereas in Julia the equivalent 
 of 
 scipy is split over many, separately developed packages (Base, Optim.jl, 
 NLopt.jl, Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of 
 these packages are stupid awesome, but they can have dramatically 
 different 
 naming conventions and calling behavior, for essential equivalent 
 behavior. 
 Recently I noticed that tolerances, for example, are named as `atol/rtol` 
 versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely 
 easy to have a piece of scientific code that will need to use all three 
 conventions across different calls to seemingly similar libraries. 

 Having brought this up I find that the community is largely sympathetic 
 and, in general, would support a common convention, the issue I have 
 slowly 
 realized is that it is rarely that straightforward. In the above example 
 the abstol/reltol versus abs_tol/rel_tol seems like an easy example of 
 what 
 can be tidied up, but the latter underscored name is consistent with 
 similar naming conventions from Optim.jl for other tolerances, so that 
 community is reluctant to change the convention. Similarly, I think there 
 would be little interest in changing abstol/reltol to the underscored 
 version in packages like Base, ODE.jl etc as this feels consistent with 
 each of these code bases. Hence I have started to think that the problem 
 is 
 the micro-packaging. It is much easier to look for consistency within a 
 package then across similar packages, and since Julia seems to distribute 
 so many of the essential tools in very narrow boundaries of functionality 
 I 
 am not sure that this kind of naming convention will ever be able to reach 
 something like a Scipy, or the even higher standard of commercial packages 
 like Matlab/Mathematica. (I am sure there are many more examples like 
 using 
 maxiter, versus iterations for describing stopping criteria in iterative 
 solvers ...)

 Even further I have noticed that even when packages try to find 
 consistency across packages, for example Optim.jl <-> Roots.jl <-> 
 NLsolve.jl, when one package changes how they do things (Optim.jl moving 
 to 
 delegation on types for method choice) then again the consistency 
 fractures 
 quickly, where we now have a common divide of using either Typed dispatch 
 keywords versus :method symbol names across the 

Re: [julia-users] Re: Julia and the Tower of Babel

[Jeffrey Sarnoff]

__JuliaPraxis__ is on [github](https://github.com/JuliaPraxis) and 
[gitter](https://gitter.im/JuliaPraxis/Lobby), 
welcoming growth.

Re: [julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

Yes, symbols would be preferred. Checking equality two symbols is quicker, 
but, more importantly, symbols are natural to Julia 
metaprogramming/expressions, meaning that if you use symbols then the 
expression is easier to generate via macros.

Tom is getting shy, but really take a look at StochasticOptimization.jl. 
Yes, it will change, but it does have a very nice design which is 
extendable and allows for the flexibility and the parameters that you need, 
and even more. Another good way to accomplish this may be call-overloaded 
types. IMHO, you may find that trying to fit an OO framework to this might 
be more work than correctly designing the framework the first time. Of 
course, YMMV.

On Sunday, October 9, 2016 at 1:07:12 PM UTC-7, Bart Janssens wrote:
>
> OK, thanks, so symbols are definitely preferred for the [] variant then?
>
> As for using dispatch, I am certainly all for designing a "proper" Julian 
> interface, but the number of parameters here can be daunting, see e.g. here 
> for a more complete example:
>
> https://github.com/barche/coolfluid3/blob/master/doc/tutorials/live_visualization/cylinder.py#L45-L57
>
> This is indeed from an object-oriented C++ framework, where we have a tree 
> of objects that each have options controlling their behavior. In the non 
> too distant future I would like for it to be possible to extend this using 
> models written in Julia (because they can be as fast as C++, but with a lot 
> less headaches for students I hope), but rewriting the entire framework is 
> just too much work right now, so I think we are stuck with this overall 
> structure for the time being.
>
> On Sun, Oct 9, 2016 at 9:13 PM Chris Rackauckas  > wrote:
>
>> Missed that one, though it should be
>>
>> mysolver[:linear_system][:parameters][:solver_type] = :GMRES
>>
>> There's no reason for an algorithm choice to be a String.
>>
>> But this entire thing seems wrong-headed. The choice of the solver method 
>> should likely be done by dispatching on the solve method somehow. This 
>> seems like trying directly match an object-oriented framework which 
>> shouldn't be recommended (look at how fast it gets messy). You may want to 
>> see if you can map a framework like StochasticOptimization.jl 
>>  to 
>> IterativeSolvers.jl .
>>
>>
>> On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson 
>> wrote:
>>>
>>> That was one of the suggestions? 
>>
>>

[julia-users] redefining Base method for `show`

[lapeyre . math122a]

I want to change show for Symbol, Rational, and Bool. Till now, I simply 
overwrote the existing methods. This works great. I get what I want, even 
in warn and error and string interpolation, etc. It works flawlessly on 
v0.4, v0.5, and v0.6. But, this changes the behavior for everyone. So, I 
want to get the same effect through different means that do not affect 
other code. Any idea about how to do this ?

One solution is to copy a large amount of  base code that uses print, 
write, show, etc. renaming these functions. Other than changing 15 or 20 
lines for Symbol, etc., the code is unchanged. This is works more or less, 
but is obviously a fragile, bad solution.

Another idea is to make a subtype of IO that wraps subtypes of IO. I am 
allowed to write methods for show for this new type. This is turning out to 
be complicated and unworkable.

Another vague idea is to make a new mime type. Another is to copy IOStream 
as another type, so that I only have to write methods for Symbol, Rational 
and Bool again.

 

[julia-users] Re: travis with dependency on scipy?

[lapeyre . math122a]

Me too. I mean, I found things worked much more smoothly after following 
this advice to use Conda. Also, Windows and OSX are supported immediately. 
Also, for my application, the Ubuntu package versions are very old, and out 
of date. This problem is solved as well.

On Friday, October 7, 2016 at 10:24:36 PM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Friday, October 7, 2016 at 9:10:44 AM UTC-4, David van Leeuwen wrote:
>>
>> Hello, 
>>
>> For a tiny package  that depends 
>> on PyCall and python's scipy.spatial I am trying to engineer a 
>> `.travis.yml`,
>>
>
> You can always do ENV["PYTHON"]="" to force PyCall to install its own 
> Python distro (via Conda), and do pyimport_conda("scipy.spatial", "scipy") 
> to make Conda install scipy for you as needed.
>
> Steven
>
> PS. As explained in the PyCall README, I don't recommend using @pyimport 
> in Modules.   Instead, do
>const spatial = PyNULL()
> and then, in your __init__ function, do copy!(spatial, 
> pyimport_conda("scipy.spatial", "scipy"))  this way, you can put 
> __precompile__(true) at the top of your module and safely precompile it.
>
> PPS. I see from your source code that you had some confusion about 
> Base.show vs. Base.display.  Never override Base.display for this sort of 
> thing.   See the new manual section for more info:
>  
> http://docs.julialang.org/en/latest/manual/types/#custom-pretty-printing
>

[julia-users] Re: Warning since 0.5

[Steven G. Johnson]

On Saturday, October 8, 2016 at 5:09:19 PM UTC-4, digxx wrote:
>
> is f(x)=x^2 not an anonymous function?!?!
>

No, it has a name "f".  An anonymous function is an expression like "x -> 
x^2" that creates a function object without binding it to a constant name. 

Re: [julia-users] Re: Setting/getting field-like members with side effects

[Bart Janssens]

OK, thanks, so symbols are definitely preferred for the [] variant then?

As for using dispatch, I am certainly all for designing a "proper" Julian
interface, but the number of parameters here can be daunting, see e.g. here
for a more complete example:
https://github.com/barche/coolfluid3/blob/master/doc/tutorials/live_visualization/cylinder.py#L45-L57

This is indeed from an object-oriented C++ framework, where we have a tree
of objects that each have options controlling their behavior. In the non
too distant future I would like for it to be possible to extend this using
models written in Julia (because they can be as fast as C++, but with a lot
less headaches for students I hope), but rewriting the entire framework is
just too much work right now, so I think we are stuck with this overall
structure for the time being.

On Sun, Oct 9, 2016 at 9:13 PM Chris Rackauckas  wrote:

> Missed that one, though it should be
>
> mysolver[:linear_system][:parameters][:solver_type] = :GMRES
>
> There's no reason for an algorithm choice to be a String.
>
> But this entire thing seems wrong-headed. The choice of the solver method
> should likely be done by dispatching on the solve method somehow. This
> seems like trying directly match an object-oriented framework which
> shouldn't be recommended (look at how fast it gets messy). You may want to
> see if you can map a framework like StochasticOptimization.jl
>  to
> IterativeSolvers.jl .
>
>
> On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote:
>
> That was one of the suggestions?
>
>

Re: [julia-users] Setting/getting field-like members with side effects

[Tom Breloff]

I think that's great, but know that StochasticOptimization is still being
designed and will likely change.

On Sunday, October 9, 2016, Chris Rackauckas  wrote:

> Missed that one, though it should be
>
> mysolver[:linear_system][:parameters][:solver_type] = :GMRES
>
> There's no reason for an algorithm choice to be a String.
>
> But this entire thing seems wrong-headed. The choice of the solver method
> should likely be done by dispatching on the solve method somehow. This
> seems like trying directly match an object-oriented framework which
> shouldn't be recommended (look at how fast it gets messy). You may want to
> see if you can map a framework like StochasticOptimization.jl
>  to
> IterativeSolvers.jl .
>
> On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote:
>>
>> That was one of the suggestions?
>
>

[julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

Missed that one, though it should be

mysolver[:linear_system][:parameters][:solver_type] = :GMRES

There's no reason for an algorithm choice to be a String.

But this entire thing seems wrong-headed. The choice of the solver method 
should likely be done by dispatching on the solve method somehow. This 
seems like trying directly match an object-oriented framework which 
shouldn't be recommended (look at how fast it gets messy). You may want to 
see if you can map a framework like StochasticOptimization.jl 
 to 
IterativeSolvers.jl .

On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote:
>
> That was one of the suggestions? 

[julia-users] Re: Setting/getting field-like members with side effects

[Kristoffer Carlsson]

That was one of the suggestions? 

Re: [julia-users] Re: macro: with

[Chris Rackauckas]

It's a lot like unpacking a type, except instead of defining new variables 
for the unpacked values, your macro places the type instance designation 
(t. ...).

On Sunday, October 9, 2016 at 10:55:45 AM UTC-7, Tom Breloff wrote:
>
> What about it?  I don't think there's anything like this in Parameters.
>
> On Sun, Oct 9, 2016 at 1:27 PM, Chris Rackauckas  > wrote:
>
>> What about Parameters.jl ?
>>
>>
>> On Wednesday, September 7, 2016 at 7:23:47 AM UTC-7, Tom Breloff wrote:
>>>
>>> Hey all... I just threw together a quick macro to save some typing when 
>>> working with the fields of an object.  Disclaimer: this should not be used 
>>> in library code, or in anything that will stick around longer than a REPL 
>>> session.  Hopefully it's self explanatory with this example.  Is there a 
>>> good home for this?  Does anyone want to use it?
>>>
>>> julia> type T; a; b; end; t = T(0,0)
>>> T(0,0)
>>>
>>> julia> macroexpand(:(
>>>@with t::T begin
>>>a = 1
>>>b = 2
>>>c = a + b - 4
>>>d = c - b
>>>a = d / c
>>>end
>>>))
>>> quote  # REPL[3], line 3:
>>> t.a = 1 # REPL[3], line 4:
>>> t.b = 2 # REPL[3], line 5:
>>> c = (t.a + t.b) - 4 # REPL[3], line 6:
>>> d = c - t.b # REPL[3], line 7:
>>> t.a = d / c
>>> end
>>>
>>> julia> @with t::T begin
>>>a = 1
>>>b = 2
>>>c = a + b - 4
>>>d = c - b
>>>a = d / c
>>>end
>>> 3.0
>>>
>>> julia> t
>>> T(3.0,2)
>>>
>>>
>

Re: [julia-users] Re: macro: with

[Tom Breloff]

What about it?  I don't think there's anything like this in Parameters.

On Sun, Oct 9, 2016 at 1:27 PM, Chris Rackauckas  wrote:

> What about Parameters.jl ?
>
>
> On Wednesday, September 7, 2016 at 7:23:47 AM UTC-7, Tom Breloff wrote:
>>
>> Hey all... I just threw together a quick macro to save some typing when
>> working with the fields of an object.  Disclaimer: this should not be used
>> in library code, or in anything that will stick around longer than a REPL
>> session.  Hopefully it's self explanatory with this example.  Is there a
>> good home for this?  Does anyone want to use it?
>>
>> julia> type T; a; b; end; t = T(0,0)
>> T(0,0)
>>
>> julia> macroexpand(:(
>>@with t::T begin
>>a = 1
>>b = 2
>>c = a + b - 4
>>d = c - b
>>a = d / c
>>end
>>))
>> quote  # REPL[3], line 3:
>> t.a = 1 # REPL[3], line 4:
>> t.b = 2 # REPL[3], line 5:
>> c = (t.a + t.b) - 4 # REPL[3], line 6:
>> d = c - t.b # REPL[3], line 7:
>> t.a = d / c
>> end
>>
>> julia> @with t::T begin
>>a = 1
>>b = 2
>>c = a + b - 4
>>d = c - b
>>a = d / c
>>end
>> 3.0
>>
>> julia> t
>> T(3.0,2)
>>
>>

[julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

Why not use Symbols instead of strings here?

On Sunday, October 9, 2016 at 8:26:57 AM UTC-7, Bart Janssens wrote:
>
> Hi all,
>
> I'm thinking about how to translate a Python interface that makes 
> extensive use of __getattr__ and __setattr__ overloading to allow chaining 
> a series of option values like this example:
> mysolver.linear_system.parameters.solver_type = "GMRES"
>
> Each time a . is encountered, the appropriate __getattr__ is called, which 
> in turn calls a C++ function to get the correct value, which may not be 
> stored as a true data field member anywhere. In the end, the assignment 
> triggers a call to __setattr__ and may call additional functions to notify 
> functions of the change. I see 3 ways of tackling this in Julia:
>
> 1. Just use methods to get/set each field, so something like:
> setproperty(getproperty(getproperty(mysolver, "linear_system"), 
> "parameters"), "solver_type", "GMRES")
> As is obvious from the example, this is a bit cumbersome and hard to read 
> with a long chain of gets.
>
> 2. Use the [] operator, which can be overloaded, as far as I understand. 
> The question there is if we use strings or symbols as keys, to get either:
> mysolver["linear_system"]["parameters"]["solver_type"] = "GMRES"
> or:
> mysolver[:linear_system][:parameters][:solver_type] = "GMRES"
> Either solution is still not as readable or easy to type as the Python 
> original
>
> 3. Finally use a macro, such as enabled by the DotOverload.jl package (
> https://github.com/sneusse/DotOverload.jl):
> @dotted mysolver.linear_system.parameters.solver_type = "GMRES"
>
> I realise this touches on the discussion on . overloading at 
> https://github.com/JuliaLang/julia/issues/1974 but that seems to have 
> dried out a bit, and I understand that touching an operation that is 
> expected to have (almost?) no inherent cost such as field access may be 
> dangerous. The macro solution in 3 seems like the most elegant method, but 
> I worry about code readability, since the purpose of the @dotted will not 
> be immediately clear to people unfamiliar with the DotOverload package. 
> Could a macro like this be provided in Base, with proper documentation 
> (near the descriptions of types and their fields, for example), so option 3 
> can be used without concerns over code readability/understandability?
>
> Cheers,
>
> Bart
>

[julia-users] Re: macro: with

[Chris Rackauckas]

What about Parameters.jl ?

On Wednesday, September 7, 2016 at 7:23:47 AM UTC-7, Tom Breloff wrote:
>
> Hey all... I just threw together a quick macro to save some typing when 
> working with the fields of an object.  Disclaimer: this should not be used 
> in library code, or in anything that will stick around longer than a REPL 
> session.  Hopefully it's self explanatory with this example.  Is there a 
> good home for this?  Does anyone want to use it?
>
> julia> type T; a; b; end; t = T(0,0)
> T(0,0)
>
> julia> macroexpand(:(
>@with t::T begin
>a = 1
>b = 2
>c = a + b - 4
>d = c - b
>a = d / c
>end
>))
> quote  # REPL[3], line 3:
> t.a = 1 # REPL[3], line 4:
> t.b = 2 # REPL[3], line 5:
> c = (t.a + t.b) - 4 # REPL[3], line 6:
> d = c - t.b # REPL[3], line 7:
> t.a = d / c
> end
>
> julia> @with t::T begin
>a = 1
>b = 2
>c = a + b - 4
>d = c - b
>a = d / c
>end
> 3.0
>
> julia> t
> T(3.0,2)
>
>

Re: [julia-users] macro: with

[Tom Breloff]

Heh... it took a google search to figure out where I put it.

https://github.com/tbreloff/CTechCommon.jl/blob/master/src/macros.jl#L113-L155

On Sun, Oct 9, 2016 at 12:19 PM, Ben Lauwens  wrote:

> Hi Tom
>
> I am interested. I am building a macro mimicking how iterator blocks are
> transformed in a state-machine in C# (as an alternative to Tasks) and this
> is one of the (many) thinks I have to solve. Can you point me to the
> source? Thanks
>
> Ben

[julia-users] macro: with

[Ben Lauwens]

Hi Tom

I am interested. I am building a macro mimicking how iterator blocks are 
transformed in a state-machine in C# (as an alternative to Tasks) and this is 
one of the (many) thinks I have to solve. Can you point me to the source? Thanks

Ben

[julia-users] Re: julia-i18n: Translators and reviewer needed!

[Lutfullah Tomak]

Inspite of initial spur, it took a while for me finish hompage for Turkish 
page 
because of the new term starting at my university. I'm not an expert in 
translation
it would be good if some other Turkish speaking user can check and give 
feedback
for my crude translation.

On Thursday, September 22, 2016 at 9:32:13 AM UTC+3, Ismael Venegas 
Castelló wrote:
>
> Looking how to contribute to Julia? Check out the web translation project 
> on Transifex. 
> Help us bring Julia internationalization to your native language one 
> string at a time!
>
>
>- https://www.transifex.com/julialang-i18n/julialang-web
>- https://gitter.im/JuliaLangEs/julia-i18n
>- https://github.com/JuliaLang/julialang.github.com/pull/252
>
>

[julia-users] Re: Setting/getting field-like members with side effects

[dnm]

What about nested modules?

Or unpure functions chained with the pipe operator? 

On Sunday, October 9, 2016 at 11:26:57 AM UTC-4, Bart Janssens wrote:
>
> Hi all,
>
> I'm thinking about how to translate a Python interface that makes 
> extensive use of __getattr__ and __setattr__ overloading to allow chaining 
> a series of option values like this example:
> mysolver.linear_system.parameters.solver_type = "GMRES"
>
> Each time a . is encountered, the appropriate __getattr__ is called, which 
> in turn calls a C++ function to get the correct value, which may not be 
> stored as a true data field member anywhere. In the end, the assignment 
> triggers a call to __setattr__ and may call additional functions to notify 
> functions of the change. I see 3 ways of tackling this in Julia:
>
> 1. Just use methods to get/set each field, so something like:
> setproperty(getproperty(getproperty(mysolver, "linear_system"), 
> "parameters"), "solver_type", "GMRES")
> As is obvious from the example, this is a bit cumbersome and hard to read 
> with a long chain of gets.
>
> 2. Use the [] operator, which can be overloaded, as far as I understand. 
> The question there is if we use strings or symbols as keys, to get either:
> mysolver["linear_system"]["parameters"]["solver_type"] = "GMRES"
> or:
> mysolver[:linear_system][:parameters][:solver_type] = "GMRES"
> Either solution is still not as readable or easy to type as the Python 
> original
>
> 3. Finally use a macro, such as enabled by the DotOverload.jl package (
> https://github.com/sneusse/DotOverload.jl):
> @dotted mysolver.linear_system.parameters.solver_type = "GMRES"
>
> I realise this touches on the discussion on . overloading at 
> https://github.com/JuliaLang/julia/issues/1974 but that seems to have 
> dried out a bit, and I understand that touching an operation that is 
> expected to have (almost?) no inherent cost such as field access may be 
> dangerous. The macro solution in 3 seems like the most elegant method, but 
> I worry about code readability, since the purpose of the @dotted will not 
> be immediately clear to people unfamiliar with the DotOverload package. 
> Could a macro like this be provided in Base, with proper documentation 
> (near the descriptions of types and their fields, for example), so option 3 
> can be used without concerns over code readability/understandability?
>
> Cheers,
>
> Bart
>

[julia-users] Setting/getting field-like members with side effects

[Bart Janssens]

Hi all,

I'm thinking about how to translate a Python interface that makes extensive
use of __getattr__ and __setattr__ overloading to allow chaining a series
of option values like this example:
mysolver.linear_system.parameters.solver_type = "GMRES"

Each time a . is encountered, the appropriate __getattr__ is called, which
in turn calls a C++ function to get the correct value, which may not be
stored as a true data field member anywhere. In the end, the assignment
triggers a call to __setattr__ and may call additional functions to notify
functions of the change. I see 3 ways of tackling this in Julia:

1. Just use methods to get/set each field, so something like:
setproperty(getproperty(getproperty(mysolver, "linear_system"),
"parameters"), "solver_type", "GMRES")
As is obvious from the example, this is a bit cumbersome and hard to read
with a long chain of gets.

2. Use the [] operator, which can be overloaded, as far as I understand.
The question there is if we use strings or symbols as keys, to get either:
mysolver["linear_system"]["parameters"]["solver_type"] = "GMRES"
or:
mysolver[:linear_system][:parameters][:solver_type] = "GMRES"
Either solution is still not as readable or easy to type as the Python
original

3. Finally use a macro, such as enabled by the DotOverload.jl package (
https://github.com/sneusse/DotOverload.jl):
@dotted mysolver.linear_system.parameters.solver_type = "GMRES"

I realise this touches on the discussion on . overloading at
https://github.com/JuliaLang/julia/issues/1974 but that seems to have dried
out a bit, and I understand that touching an operation that is expected to
have (almost?) no inherent cost such as field access may be dangerous. The
macro solution in 3 seems like the most elegant method, but I worry about
code readability, since the purpose of the @dotted will not be immediately
clear to people unfamiliar with the DotOverload package. Could a macro like
this be provided in Base, with proper documentation (near the descriptions
of types and their fields, for example), so option 3 can be used without
concerns over code readability/understandability?

Cheers,

Bart

Re: [julia-users] Re: Julia and the Tower of Babel

[Michael Borregaard]

Great to see this brought up here, and to read the constructive and 
thought-provoking responses from members of the Julia community. I feel 
this is highly important and I have thougt a lot about it recently, as I am 
writing an invited guest editorial for a leading ecological journal about 
how transferring to julia as the lingua franca for ecological scientists 
may affect the way we do science and work together.

I come to this from a somewhat different angle, as the ecological community 
is almost 100% wedded to R – the use of R has practically exploded within 
the last 5 years alone. So when I came to julia I was struck by how 
structured the package ecosystem appears to be, yet, in spite of the 
micropackaging. This seems to me to be a huge advantage for collaboration, 
creativity and methods development, and IMHO this will in the end be a 
stronger argument for our community to make the transition than the speed 
of computation.

I think there are a number of reasons for this difference, but I also 
believe that a primary reason is the reliance on github for developing the 
package ecosystem from the bottom up, and the use of organizations. These 
organisations, like JuliaGeo, BioJulia etc in effect act like standard 
package distributions, both by facilitating communication within, but also 
by imposing a set of strict guidelines on code compatibility. Centrally, 
the organisations are really visible centers for where development in a 
given field takes place, and thus the culture encourages developers to 
contribute to existing packages and organisations rather than inventing new 
packages. In R that is not the case - instead most scientific packages are 
one-lab projects developed to serve a certain research program. 

I do hope that this can continue in the future, but one might worry: right 
now most julia developers are driven by a desire to help build the language 
itself, but when it grows over a certain size and becomes established this 
is sure to become less pronounced. Also, the current practice of software 
papers in scientific journals means that researchers get credit for 
developing new packages, but none for contributing to existing packages. 
This directly counteracts the best interests of the community.

It is a new situation to have a scientific language that is built openly 
and communally, yet with such a high degree of integration and 
communication. The solution must be culture, as written by Stefan and Tom, 
specifically to develop the community culture to keep communicating, 
discussing and agreeing upon standards. Also, for instance, organizations 
like the biojulia community are very good at identifying new ad-hoc 
packages coming out that relate to their work, and invite developers to 
join the communal effort and build the foundation of Julia in their field 
instead of creating lots of partial alternatives. I think this is key.

But perhaps this could be strengthened by being more explicit about 
building modular 'standard libraries', like in the respective 
organizations, but perhaps also for base (or statistics/numerical analysis, 
at least) that impose strict internal guidelines for conformance? These 
organizations, of course, would need mechanisms for ensuring renewal within 
the basic ideoms, so development does not die.

I for one will follow this development with keen interest.

[julia-users] Re: BinDeps / LoadError: Path /home/travis/.julia/v0.5/TALib/deps/src/ta-lib-0.4.0-src was not created successfully

[Femto Trader]

I'm doing

provides(BuildProcess, Autotools(libtarget = "libta_lib", 
configure_options=["--prefix=/usr"]), libta_lib, os = :Unix)

Is --prefix=/usr  "local prefix" or a "system-wide" prefix ?


If it's a system-wide prefix... how to use a local prefix ?

Sorry for my newbies questions about build.
 

Le dimanche 9 octobre 2016 04:45:57 UTC+2, Tony Kelman a écrit :
>
> sounds like the library can't handle out of tree builds? you should also 
> use a local prefix, not a system-wide one that would require sudo.