[julia-users] Re: Dual licenses for Julia packages

[Páll Haraldsson]

On Friday, February 5, 2016 at 3:10:54 PM UTC, Scott Jones wrote:
>
> I'm curious about how one could release packages for use with Julia such 
> that they would be free for non-commercial use (under GPL maybe?) but also 
> available with a paid license for commercial use.
>

I guess you know, it's just not completely clear: You can't release under 
GPL and, say only non-commercial is only ok (neither can you with any 
permissive/OSI certified license or DFSG-compliant that inspired OSI/it's 
based on).

Effectively, even if GPL allows commercial use, you might be putting off 
many of your competitors, by using it, because of it "viral" (or 
"spider-plant"-nature). Since/when you own the copyright you can release 
under any other (proprietary) license forcing to pay, for using and getting 
out of the viral nature.

One thing the GPL (or any license? at least free/open source) doesn't 
forbid (and it's not like it's easy to know anyway), is using privately 
within you whole organization/company. Then you can link with whatever 
other software (just not distribute/convey outside).

One even stricter license, might help you, AGPL based on the GPLv3. Then 
you force your competitor to release code, if the code to any user of a 
server you have ("software as a service").


https://people.debian.org/~bap/dfsg-faq.html

https://www.debian.org/social_contract

https://opensource.org/licenses

Has anybody else done this?
>
> As much as possible, I'd like to release things under the MIT license, 
> however, there are many things that might be useful to other Julians, that 
> they (the company I'm consulting for) don't want to give away for free to a 
> commercial competitor (we need to eat also!).
>
>
>

[julia-users] I think I'm obtaining the nightly ubuntu PPA incorrectly...

[Jeff Waller]

For travis

sudo add-apt-repository ppa:staticfloat/julianightlies

I end up with one from November


1.81s$ julia -e 'versioninfo()'

Julia Version 0.5.0-dev+1491

Commit 41fb1ba (2015-11-27 16:54 UTC)

Platform Info:

System: Linux (x86_64-linux-gnu)

CPU: Intel(R) Xeon(R) CPU @ 2.30GHz

WORD_SIZE: 64

BLAS: libopenblas (NO_LAPACK NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Haswell)

LAPACK: liblapack.so.3

LIBM: libopenlibm

LLVM: libLLVM-3.3

Re: [julia-users] equivalent of python's string.title() in julia

[Stefan Karpinski]

Since there was talk of removing uppercase and lowercase altogether (I was
against this), I felt it would be pushing it to add titlecase, but a good
PR to do this would be welcomed.

On Fri, Feb 5, 2016 at 4:06 AM, Milan Bouchet-Valat 
wrote:

> Le jeudi 04 février 2016 à 17:31 -0800, julialangfans...@gmail.com a
> écrit :
> > in python, "abc def ghi jkl".title() capitalizes each "word" in the
> > string, giving 'Abc Def Ghi Jkl' as the result
> >
> > i have not been able to find a similar string function in julia, so
> > i'm currently doing this:
> >
> > julia> join(map(ucfirst, split("abc def ghi jkl")), " ")
> > "Abc Def Ghi Jkl"
> >
> > is there a better / more straightforward julia-based solution?
> I wouldn't call it "straightforward", but if you need a Unicode-correct
> way of applying title case, you can use UnicodeExtras, which relies on
> ICU:
> https://github.com/nolta/UnicodeExtras.jl#case-handling
>
> Title case hasn't been implemented in base yet, though it's been
> mentioned in the past:
> https://github.com/JuliaLang/julia/issues/11471
> https://github.com/JuliaLang/julia/issues/774
>
>
> Regards
>

Re: [julia-users] julia -machinefile help

[Stefan Karpinski]

I didn't notice the subject, which indicates that you're having some
trouble with machine files, rather than wanting to know about distributed
computing in general. Can you be more specific about what the problem is?

On Fri, Feb 5, 2016 at 10:07 AM, Stefan Karpinski 
wrote:

> http://docs.julialang.org/en/latest/manual/parallel-computing/
>
> On Fri, Feb 5, 2016 at 10:02 AM, Vishnu Raj 
> wrote:
>
>> Hi,
>>
>> Can some provide any pointers on how to configure julia to run
>> distributed code?
>> I want to configure three macs to run my distributed code.
>>
>
>

Re: [julia-users] Memory allocation free array slices ?

[Kevin Squire]

>
> julia> @time bar
>   0.01 seconds (3 allocations: 144 bytes)
> bar (generic function with 1 method)
>

I think this needs to be @time bar(A).  I get

julia> @time bar(A)
  0.000269 seconds (5 allocations: 176 bytes)
20010.937886591404

[julia-users] Re: how to undefine variable in composite types

[Scott Jones]

Types themselves are immutable, right?
Don't instances in Julia contain a pointer to their type?
If a type's definition were replaced, would the old (now obsolete) 
instances still point to the old definition?  Would they still correctly 
use methods specialized on the old definition?
If so, it seems that you could redefine types without much problem, as long 
as you didn't expect the
old instance's data to be migrated.

I think that would be very useful in the REPL.
Often I have lots of data in objects totally unaffected by the type I'm 
working on, and it's a pain to have to save data, restart, recompile, 
reload data constantly during development.

On Thursday, February 4, 2016 at 1:46:45 PM UTC-5, Michael Landis wrote:
>
> I think it would be nice to be able to undefine a type, so restarting the 
> environment is not required when adding or deleting an attribute from a 
> type description.  Not being able to update a type definition without 
> restarting the environment is a royal pain in the ass.
>
> On Saturday, March 8, 2014 at 9:55:37 AM UTC-8, Freddy Chua wrote:
>>
>> Suppose I have a Type
>>
>> type Foo
>>   a
>>   b
>> end
>>
>> f = Foo(1,2)
>> f.a = 1
>> f.b = 2
>>
>> how do I test whether f.a is defined
>> I do this isdefined(f, 1) but isdefined(f, 'a') does not work
>>
>> another question
>> how do i undefine f.a such that isdefined(f,1) now returns false
>>
>

Re: [julia-users] julia -machinefile help

[Vishnu Raj]

Sorry for the ambiguity. 
What I want to know is about the contents of machinefile, how to configure 
remote systems for accepting the connections.
Like a step by step procedure for bringing up a network of computers and 
deploying distributed code in the.


On Friday, February 5, 2016 at 8:43:20 PM UTC+5:30, Stefan Karpinski wrote:
>
> I didn't notice the subject, which indicates that you're having some 
> trouble with machine files, rather than wanting to know about distributed 
> computing in general. Can you be more specific about what the problem is?
>
> On Fri, Feb 5, 2016 at 10:07 AM, Stefan Karpinski  > wrote:
>
>> http://docs.julialang.org/en/latest/manual/parallel-computing/
>>
>> On Fri, Feb 5, 2016 at 10:02 AM, Vishnu Raj > > wrote:
>>
>>> Hi,
>>>
>>> Can some provide any pointers on how to configure julia to run 
>>> distributed code?
>>> I want to configure three macs to run my distributed code.
>>>
>>
>>
>

[julia-users] Dual licenses for Julia packages

[Scott Jones]

I'm curious about how one could release packages for use with Julia such 
that they would be free for non-commercial use (under GPL maybe?) but also 
available with a paid license for commercial use.

Has anybody else done this?

As much as possible, I'd like to release things under the MIT license, 
however, there are many things that might be useful to other Julians, that 
they (the company I'm consulting for) don't want to give away for free to a 
commercial competitor (we need to eat also!).

Re: [julia-users] Re: how to undefine variable in composite types

[Stefan Karpinski]

Python has less of a problem here since it represents object data using a
dict internally – when you reload a class, the representation of objects
doesn't change. Still, if adding or removing fields in Python classes works
at all, that's an interesting data point.

On Fri, Feb 5, 2016 at 5:24 AM, Andras Niedermayer 
wrote:

> class X(object):
> @property
> def y(self):
> try: return x.__y
> except AttributeError: return "default value for y"
>
> x = X()
> print x.y
>
>
>
>
>
> On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer wrote:
>>
>> The IPython autoreload extension does something quite similar to what has
>> been discussed here (
>> https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ).
>> There are cases where it's actually very convenient, e.g. if you have
>> results from a long-running calculation in an IPython notebook interactive
>> session and you notice that you should change one of the classes, but don't
>> want to rerun the whole calculation.
>>
>> Some of this one gets almost for free in Julia with the Autoreload.jl
>> package, since methods are outside of types in Julia, so there's no need to
>> search for all object of a modified type in memory and add/modify the
>> methods like in Python. (Modifying inlined methods is a bit of a problem,
>> but one could probably extend Autoreload.jl to inject @noinline into
>> modules.)
>>
>> Adding fields would only be possible in Julia if it were possible to
>> overload field access ( https://github.com/JuliaLang/julia/issues/1974
>> ).
>>
>> That's essentially the way one does this in Python. You add a property
>> getter y to class X, which allows you to access x.y:
>>
>> class X(object):
>>
>>
>>
>>
>> On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:
>>>
>>> My main concern is predictability.
>>>
>>> Imagine that I define a type Foo and start playing around with it -
>>> define some functions that work on foot, perhaps one or two types that hold
>>> foos, and manipulate a bunch of Foo instances.
>>>
>>> Then, I redefine the Foo type - say, I add a field. Which of the other
>>> things that I have defined are still valid?
>>>
>>> If I understand the motivation for this feature correctly, it's to make
>>> exploratory programming easier. However, I think it would actually make it
>>> a lot more difficult - it would basically give you a bazooka so heavy that
>>> the only thing you can reasonably aim at is your own foot...
>>>
>>> //T
>>>
>>>

[julia-users] julia -machinefile help

[Vishnu Raj]

Hi,

Can some provide any pointers on how to configure julia to run distributed 
code?
I want to configure three macs to run my distributed code.

[julia-users] equivalent of python's string.title() in julia

[Ismael Venegas Castelló]

I made this IJulia gist:

bit.ly/JLTitle

Re: [julia-users] Dual licenses for Julia packages

[Tom Breloff]

Scott I'm curious about this as well, however I tend to think that there's
no good solution.  The problem isn't in an end user picking up your package
(Package A) and using it commercially vs non-commercially.  The problem
comes when someone wants to build some sort of derivative work (Package B)
and then the end user of *their* package doesn't know about the licensing
issues.  To resolve, then Package B needs to carry forward licenses from
Package A, and the end-user of Package B has to worry about multiple layers
of licensing.  YUCK

Also, you run into tricky (but common) edge cases of what constitutes
commercial use (though maybe someone more knowledgeable about this stuff
wouldn't think they are edge cases).

I personally hate dual licenses because of the mental headache that ensues,
which is why I've been either releasing my code as MIT or not at all.  If
you come up with an easy-to-manage solution, please let me know.

On Fri, Feb 5, 2016 at 10:01 AM, Scott Jones 
wrote:

> I'm curious about how one could release packages for use with Julia such
> that they would be free for non-commercial use (under GPL maybe?) but also
> available with a paid license for commercial use.
>
> Has anybody else done this?
>
> As much as possible, I'd like to release things under the MIT license,
> however, there are many things that might be useful to other Julians, that
> they (the company I'm consulting for) don't want to give away for free to a
> commercial competitor (we need to eat also!).
>
>
>

Re: [julia-users] julia -machinefile help

[Stefan Karpinski]

http://docs.julialang.org/en/latest/manual/parallel-computing/

On Fri, Feb 5, 2016 at 10:02 AM, Vishnu Raj  wrote:

> Hi,
>
> Can some provide any pointers on how to configure julia to run distributed
> code?
> I want to configure three macs to run my distributed code.
>

Re: [julia-users] Re: how to undefine variable in composite types

[Stefan Karpinski]

Even assuming feasibility, implementing this in Julia is a total nightmare
– you'd have to recompile huge amounts of code and reconstruct lots of
objects – and anything that refers to them, etc. It's almost easier to
serialize the entire workspace and reload all code. Basically, the amount
of work required makes #265 
look like child's play. Bottom line, I don't think it's going to happen
unless someone who feels strongly about it makes a solid pull request to
implement it. And there seems to be a negative correlation between the
ability to implement this and thinking that it's a good idea to do so.

On Fri, Feb 5, 2016 at 9:55 AM, Stefan Karpinski 
wrote:

> Python has less of a problem here since it represents object data using a
> dict internally – when you reload a class, the representation of objects
> doesn't change. Still, if adding or removing fields in Python classes works
> at all, that's an interesting data point.
>
> On Fri, Feb 5, 2016 at 5:24 AM, Andras Niedermayer <
> afniederma...@gmail.com> wrote:
>
>> class X(object):
>> @property
>> def y(self):
>> try: return x.__y
>> except AttributeError: return "default value for y"
>>
>> x = X()
>> print x.y
>>
>>
>>
>>
>>
>> On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer
>> wrote:
>>>
>>> The IPython autoreload extension does something quite similar to what
>>> has been discussed here (
>>> https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ).
>>> There are cases where it's actually very convenient, e.g. if you have
>>> results from a long-running calculation in an IPython notebook interactive
>>> session and you notice that you should change one of the classes, but don't
>>> want to rerun the whole calculation.
>>>
>>> Some of this one gets almost for free in Julia with the Autoreload.jl
>>> package, since methods are outside of types in Julia, so there's no need to
>>> search for all object of a modified type in memory and add/modify the
>>> methods like in Python. (Modifying inlined methods is a bit of a problem,
>>> but one could probably extend Autoreload.jl to inject @noinline into
>>> modules.)
>>>
>>> Adding fields would only be possible in Julia if it were possible to
>>> overload field access ( https://github.com/JuliaLang/julia/issues/1974
>>> ).
>>>
>>> That's essentially the way one does this in Python. You add a property
>>> getter y to class X, which allows you to access x.y:
>>>
>>> class X(object):
>>>
>>>
>>>
>>>
>>> On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:

 My main concern is predictability.

 Imagine that I define a type Foo and start playing around with it -
 define some functions that work on foot, perhaps one or two types that hold
 foos, and manipulate a bunch of Foo instances.

 Then, I redefine the Foo type - say, I add a field. Which of the other
 things that I have defined are still valid?

 If I understand the motivation for this feature correctly, it's to make
 exploratory programming easier. However, I think it would actually make it
 a lot more difficult - it would basically give you a bazooka so heavy that
 the only thing you can reasonably aim at is your own foot...

 //T


>

Re: [julia-users] Dual licenses for Julia packages

[Scott Jones]

I'm afraid that it may end up that way for me as well, releasing what's 
acceptable to the company (and stuff I do purely as non-related side 
projects) under MIT, or not at all. ☹️

After decades never being able to show my code to the world, I do enjoy the 
openness and usefulness of the MIT license, both being able to use any MIT 
code for my commercial projects, and being able to pay forward by 
contributing myself.

On Friday, February 5, 2016 at 10:27:03 AM UTC-5, Tom Breloff wrote:
>
> Scott I'm curious about this as well, however I tend to think that there's 
> no good solution.  The problem isn't in an end user picking up your package 
> (Package A) and using it commercially vs non-commercially.  The problem 
> comes when someone wants to build some sort of derivative work (Package B) 
> and then the end user of *their* package doesn't know about the licensing 
> issues.  To resolve, then Package B needs to carry forward licenses from 
> Package A, and the end-user of Package B has to worry about multiple layers 
> of licensing.  YUCK
>
> Also, you run into tricky (but common) edge cases of what constitutes 
> commercial use (though maybe someone more knowledgeable about this stuff 
> wouldn't think they are edge cases).
>
> I personally hate dual licenses because of the mental headache that 
> ensues, which is why I've been either releasing my code as MIT or not at 
> all.  If you come up with an easy-to-manage solution, please let me know.
>
> On Fri, Feb 5, 2016 at 10:01 AM, Scott Jones  > wrote:
>
>> I'm curious about how one could release packages for use with Julia such 
>> that they would be free for non-commercial use (under GPL maybe?) but also 
>> available with a paid license for commercial use.
>>
>> Has anybody else done this?
>>
>> As much as possible, I'd like to release things under the MIT license, 
>> however, there are many things that might be useful to other Julians, that 
>> they (the company I'm consulting for) don't want to give away for free to a 
>> commercial competitor (we need to eat also!).
>>
>>
>>
>

Re: [julia-users] Re: how to undefine variable in composite types

[Kevin Squire]

An easier path forward might be to mimic python types with dictionaries and
macros (and containers for the dictionaries).

On Fri, Feb 5, 2016 at 7:04 AM, Stefan Karpinski 
wrote:

> Even assuming feasibility, implementing this in Julia is a total nightmare
> – you'd have to recompile huge amounts of code and reconstruct lots of
> objects – and anything that refers to them, etc. It's almost easier to
> serialize the entire workspace and reload all code. Basically, the amount
> of work required makes #265
>  look like child's play.
> Bottom line, I don't think it's going to happen unless someone who feels
> strongly about it makes a solid pull request to implement it. And there
> seems to be a negative correlation between the ability to implement this
> and thinking that it's a good idea to do so.
>
> On Fri, Feb 5, 2016 at 9:55 AM, Stefan Karpinski 
> wrote:
>
>> Python has less of a problem here since it represents object data using a
>> dict internally – when you reload a class, the representation of objects
>> doesn't change. Still, if adding or removing fields in Python classes works
>> at all, that's an interesting data point.
>>
>> On Fri, Feb 5, 2016 at 5:24 AM, Andras Niedermayer <
>> afniederma...@gmail.com> wrote:
>>
>>> class X(object):
>>> @property
>>> def y(self):
>>> try: return x.__y
>>> except AttributeError: return "default value for y"
>>>
>>> x = X()
>>> print x.y
>>>
>>>
>>>
>>>
>>>
>>> On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer
>>> wrote:

 The IPython autoreload extension does something quite similar to what
 has been discussed here (
 https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ).
 There are cases where it's actually very convenient, e.g. if you have
 results from a long-running calculation in an IPython notebook interactive
 session and you notice that you should change one of the classes, but don't
 want to rerun the whole calculation.

 Some of this one gets almost for free in Julia with the Autoreload.jl
 package, since methods are outside of types in Julia, so there's no need to
 search for all object of a modified type in memory and add/modify the
 methods like in Python. (Modifying inlined methods is a bit of a problem,
 but one could probably extend Autoreload.jl to inject @noinline into
 modules.)

 Adding fields would only be possible in Julia if it were possible to
 overload field access ( https://github.com/JuliaLang/julia/issues/1974
 ).

 That's essentially the way one does this in Python. You add a property
 getter y to class X, which allows you to access x.y:

 class X(object):




 On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:
>
> My main concern is predictability.
>
> Imagine that I define a type Foo and start playing around with it -
> define some functions that work on foot, perhaps one or two types that 
> hold
> foos, and manipulate a bunch of Foo instances.
>
> Then, I redefine the Foo type - say, I add a field. Which of the other
> things that I have defined are still valid?
>
> If I understand the motivation for this feature correctly, it's to
> make exploratory programming easier. However, I think it would actually
> make it a lot more difficult - it would basically give you a bazooka so
> heavy that the only thing you can reasonably aim at is your own foot...
>
> //T
>
>
>>
>

RE: [julia-users] load a Julia dataframe from Microsoft SQL Server table

[David Anthoff]

https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255 

 =-2147217396

 

suggests that if you call the version without the A or W suffix you get the 
ANSI version. 

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Scott Jones
Sent: Thursday, February 4, 2016 1:55 PM
To: julia-users 
Subject: Re: [julia-users] load a Julia dataframe from Microsoft SQL Server 
table

 



On Thursday, February 4, 2016 at 4:29:46 PM UTC-5, Stefan Karpinski wrote:

On Thu, Feb 4, 2016 at 1:50 PM, Scott Jones  wrote:

 

This still doesn't explain why some drivers are accepting UCS-2/UTF-16 when 
called with the non-Unicode API.

 

When you do so, are you actually calling the functions with the A, or just the 
macro without either A or W?

The macro will compile to either the A or the W form, depending on how your 
application is built.

 

This is a better page in MSDN: 
https://msdn.microsoft.com/en-us/library/ms712612(v=vs.85).aspx describing what 
is going on.

 

The ODBC package calls the functions without A or W. What it's calling can't be 
a macro since macros aren't callable via ccall. But changing ODBC to call the W 
version of everything may be the fix here.

 

That very well may be the solution: looking for example at libiodbc on the Mac, 
it has 3 different versions of all those functions, and I'm not sure just what 
behavior you get when using the form without the A or W.  I've always used ODBC 
with the C headers, unlike the direct linking that Julia is doing, so that it 
always gets the W version since I compile as a Unicode build. 

[julia-users] Re: Solve ode with initial conditions

[j verzani]

Similar things can be done. Rather than illustrate, I'll point out instead 
that I just added an interface to `dsolve` that makes this much more 
straightforward 
(https://github.com/jverzani/SymPy.jl/blob/master/src/dsolve.jl#L87). I'll 
tag a new version soon.

On Friday, February 5, 2016 at 8:18:36 AM UTC-5, jmarcell...@ufpi.edu.br 
wrote:
>
> Hi j
> very good,thanks! very practical. For a second order ode, as would be?
>
>
> Em sexta-feira, 5 de fevereiro de 2016 01:50:34 UTC-2, j verzani escreveu:
>>
>> It can be a bit cleaner to just get the constant if you substitute as the 
>> following:
>>
>> eqn = diff(u(x),x) - 2u(x)   # for example
>> out = dsolve(eqn)
>> solve(out(u(x) => y0, x=> x0))
>>
>> On Thursday, February 4, 2016 at 2:25:04 PM UTC-5, 
>> jmarcell...@ufpi.edu.br wrote:
>>>
>>> Hi j
>>> in fact, the solution is not easy. I got your tip and made this way:
>>>
>>> C1 = Sym("C1")
>>>
>>> # eq1 na forma: substituir x por 0 na parte direita da sol_simb
>>> # e subtrair a expressao pelo valor de y0
>>>
>>> eq1 = subs(rhs(sol_simb),x=>0) - 1
>>>
>>> SymPy.solve(eq1,C1)
>>>
>>>
>>>
>>>
>>> Em quinta-feira, 4 de fevereiro de 2016 11:23:15 UTC-2, j verzani 
>>> escreveu:

 Then this should work where `u` is the Symbolic Function and eqn is 
 just `diff(u(x),x) - 2u(x)`: `dsolve(eqn, ics=Dict(u(x0)=>y0))`, but it 
 doesn't for me :( I think the problem is that initial conditions seem to 
 only work with the power series method. For this problem this call will 
 work with an initial condition: `dsolve(eqn, ics=Dict(u(x0)=>y0), 
 hint="1st_power_series")`. Which isn't too satisfying, as there is an 
 exact 
 answer.

 --J

 On Thursday, February 4, 2016 at 7:47:14 AM UTC-5, 
 jmarcell...@ufpi.edu.br wrote:
>
> Hi j verzani
>
>
>  SymPy documentation has the "ics", but does not show example: dsolve(
> *eq*, *func=None*, *hint='default'*, *simplify=True*, *ics=None*, 
> *xi=None*, *eta=None*, *x0=0*, *n=6*, ***kwargs*)
> any tips?
>
> Em quinta-feira, 4 de fevereiro de 2016 02:01:20 UTC-2, j verzani 
> escreveu:
>>
>> There may be a better way, but here is one that works:
>>
>> * extract the RHS of the output: eqn = rhs(out)
>> * find the symbol for C1 from the output of free_symbols(eqn)
>> * if (x0,y0) are your initial conditions, then: solve(eqn(x=>x0) - 
>> y0, C1)
>>
>>
>>
>> On Wednesday, February 3, 2016 at 10:43:30 PM UTC-5, 
>> jmarcell...@ufpi.edu.br wrote:
>>>
>>> I want to solve an ode with initial conditions. For example
>>> using SymPy
>>> f   = SymFunction("f")
>>> x,y = Sym("x,y")
>>>
>>> edo1 = SymPy.diff(f(x),x) + x 
>>>
>>> SymPy.dsolve(edo1)
>>>
>>> f(x) == C1 - x^2/2
>>>
>>>
>>>
>>>
>>> How to solve C1?
>>>
>>

Re: [julia-users] load a Julia dataframe from Microsoft SQL Server table

[Stefan Karpinski]

It does, but that's not what we're seeing – at least with some ODBC drivers.

On Fri, Feb 5, 2016 at 1:18 PM, David Anthoff  wrote:

>
> https://msdn.microsoft.com/en-us/library/ms716246%28v=vs.85%29.aspx?f=255=-2147217396
>
>
>
> suggests that if you call the version without the A or W suffix you get
> the ANSI version.
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Scott Jones
> *Sent:* Thursday, February 4, 2016 1:55 PM
> *To:* julia-users 
> *Subject:* Re: [julia-users] load a Julia dataframe from Microsoft SQL
> Server table
>
>
>
>
>
> On Thursday, February 4, 2016 at 4:29:46 PM UTC-5, Stefan Karpinski wrote:
>
> On Thu, Feb 4, 2016 at 1:50 PM, Scott Jones  wrote:
>
>
>
> This still doesn't explain why some drivers are accepting UCS-2/UTF-16
> when called with the non-Unicode API.
>
>
>
> When you do so, are you actually calling the functions with the A, or just
> the macro without either A or W?
>
> The macro will compile to either the A or the W form, depending on how
> your application is built.
>
>
>
> This is a better page in MSDN:
> https://msdn.microsoft.com/en-us/library/ms712612(v=vs.85).aspx describing
> what is going on.
>
>
>
> The ODBC package calls the functions without A or W. What it's calling
> can't be a macro since macros aren't callable via ccall. But changing ODBC
> to call the W version of everything may be the fix here.
>
>
>
> That very well may be the solution: looking for example at libiodbc on the
> Mac, it has 3 different versions of all those functions, and I'm not sure
> just what behavior you get when using the form without the A or W.  I've
> always used ODBC with the C headers, unlike the direct linking that Julia
> is doing, so that it always gets the W version since I compile as a Unicode
> build.
>

Re: [julia-users] equivalent of python's string.title() in julia

[Steven G. Johnson]

On Friday, February 5, 2016 at 4:06:40 AM UTC-5, Milan Bouchet-Valat wrote:
>
> > is there a better / more straightforward julia-based solution? 
> I wouldn't call it "straightforward", but if you need a Unicode-correct 
> way of applying title case, you can use UnicodeExtras, which relies on 
> ICU: 
> https://github.com/nolta/UnicodeExtras.jl#case-handling 
>

utf8proc (which is used internally for Unicode transformations by Julia) 
has Unicode-aware titlecase mapping, but we don't currently export that; 
would require an easy PR similar to 
https://github.com/JuliaLang/utf8proc/pull/40 

[julia-users] Re: Dual licenses for Julia packages

[Tobias Knopp]

This question is by no mean specific to Julia. You have to release the 
software under GPL (v2/v3) and of course as a copyright holder you are 
allowed to use it commercially. If you want others to contribute to your 
package you need them to agree that the code will be used by you under a 
commercial license (have a look how ubuntu handles it)

One of the prominent software that is both GPL an commercial is FFTW (e.g. 
part of matlab).

Cheers,

Tobi

Am Freitag, 5. Februar 2016 16:10:54 UTC+1 schrieb Scott Jones:
>
> I'm curious about how one could release packages for use with Julia such 
> that they would be free for non-commercial use (under GPL maybe?) but also 
> available with a paid license for commercial use.
>
> Has anybody else done this?
>
> As much as possible, I'd like to release things under the MIT license, 
> however, there are many things that might be useful to other Julians, that 
> they (the company I'm consulting for) don't want to give away for free to a 
> commercial competitor (we need to eat also!).
>
>
>

[julia-users] equivalent of python's string.title() in julia

[Ismael Venegas Castelló]

You can do something like:

title(s::AbstractString) = join([ucfirst(w) for w in split(s, ' ')], ' 
')::typeof(s)

[julia-users] Re: associating outer constructors with different names with a type

[Christopher Alexander]

Instead of having the name be ASCIIString, you could have that be another 
type like SomeTypeName, (which then has the string "A" or "B" as an 
attribute).  Then you could do a type alias to map TypeA to 
SomeType{SomeTypeA} and TypeB to SomeType{SomeTypeB} assuming SomeTypeA and 
SomeTypeB are types that extend an abstract type SomeTypeName.

For example, I have something like this in one of my projects:

abstract ModelType
abstract Model

# model types
type AffineModelType <: ModelType end
type TermStructureConsistentModelType <: ModelType end

# type aliases
typealias AffineModel Model{AffineModelType}
typealias TermStructureConsistentModel 
Model{TermStructureConsistentModelType}

Someone else feel free to chime in if this isn't really the best way, as 
I'm still learning too!

Chris

On Friday, February 5, 2016 at 4:16:24 PM UTC-5, Uri Patish wrote:
>
> Hi,
>
> I was wondering what is the best way going about the following issue. 
> Suppose I have a type with few outer constructors which I name differently, 
> and I want Julia to recognize these functions as constructors of that type. 
> For example
>
> type SomeType <: SomeAbstract
>   name::ASCIIString
>   value::Int
> end
>
> TypeA(value::Int) = SomeType("A", value)
> TypeB(value::Int) = SomeType("B", value)
>
> In this case, I have two pseudo-types, TypeA and TypeB, which have the 
> same structure and are only different by their state. The problem with this 
> approach is that now TypeA and TypeB are functions and not datatypes, thus, 
> I cannot use operations defined on datetypes like checking for subtyping 
> (TypeA 
> <: SomeAbstract), or overloading type construction using call. 
>
> Clearly, I could have defined two types which have exactly the same 
> structure but this seems wrong to me as it involes code replication. 
> Another possible solution is to define a macro which defines the type and 
> its outer constructor, and I would call the macro to define TypeA and 
> TypeB. Nonetheless, I was wondering if there was a way to tell Julia that 
> the functions TypeA and TypeB are in fact constructors of SomeType. I'd be 
> glag to hear about other solutions as well. 
>
> Uri
>
>
>

Re: [julia-users] Memory allocation free array slices ?

[Tim Holy]

On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote:
> I think this needs to be @time bar(A).

Yeah, sorry for the typo.

> I get
> 
> julia> @time bar(A)
>   0.000269 seconds (5 allocations: 176 bytes)
> 20010.937886591404

That's just REPL allocation. Since A has 1 columns, if this strategy were 
allocating you'd expect "1+n allocations," where n comes from the REPL.

--Tim

[julia-users] Re: Solve ode with initial conditions

[j verzani]

Yes, this now can be done with:

y = IVPSolution("y")
x  = Sym("x")

eqn = y''(x) - 4y(x) - x
ivpsolve(eqn, x, (y, 0, 1), (y', 0, 0))


I added a few examples to the tutorial 
(https://github.com/jverzani/SymPy.jl/blob/master/examples/tutorial.md#initial-value-problems).
 
I'm not entirely happy with the names and could specify the initial 
conditions differently `y' => (x0, y0)`, say, but otherwise this seems to 
simplify this task quite a bit.

On Friday, February 5, 2016 at 3:03:07 PM UTC-5, jmarcell...@ufpi.edu.br 
wrote:
>
>
> Very good. I hope looking forward to the new version. Idea Code:
>
> using SymPy
>
> y   = SymFunction("y")
> x   = Sym("x")
>
> edo2 = SymPy.diff(y(x),x,x) - 4*y(x)-x
>
> sol_simb_ord2 = SymPy.dsolve(edo2)
>
> C1,C2 = Sym("C1,C2")
>
> eq1 = sol_simb_ord2(y(x) => 1, x=> 0)
>
> eq2 = SymPy.diff((sol_simb_ord2),x)(diff(y(x)) => 0, x=> 0)
>
> coef = solve([eq1,eq2])
>
> sol_geral = SymPy.subs(sol_simb_ord2,C1=>coef[C1],C2=>coef[C2])
>
> g(x) = rhs(sol_geral)
>
> g(x)
>
>
> Em sexta-feira, 5 de fevereiro de 2016 16:14:00 UTC-2, j verzani escreveu:
>>
>> Similar things can be done. Rather than illustrate, I'll point out 
>> instead that I just added an interface to `dsolve` that makes this much 
>> more straightforward (
>> https://github.com/jverzani/SymPy.jl/blob/master/src/dsolve.jl#L87). 
>> I'll tag a new version soon.
>>
>> On Friday, February 5, 2016 at 8:18:36 AM UTC-5, jmarcell...@ufpi.edu.br 
>> wrote:
>>>
>>> Hi j
>>> very good,thanks! very practical. For a second order ode, as would be?
>>>
>>>
>>> Em sexta-feira, 5 de fevereiro de 2016 01:50:34 UTC-2, j verzani 
>>> escreveu:

 It can be a bit cleaner to just get the constant if you substitute as 
 the following:

 eqn = diff(u(x),x) - 2u(x)   # for example
 out = dsolve(eqn)
 solve(out(u(x) => y0, x=> x0))

 On Thursday, February 4, 2016 at 2:25:04 PM UTC-5, 
 jmarcell...@ufpi.edu.br wrote:
>
> Hi j
> in fact, the solution is not easy. I got your tip and made this way:
>
> C1 = Sym("C1")
>
> # eq1 na forma: substituir x por 0 na parte direita da sol_simb
> # e subtrair a expressao pelo valor de y0
>
> eq1 = subs(rhs(sol_simb),x=>0) - 1
>
> SymPy.solve(eq1,C1)
>
>
>
>
> Em quinta-feira, 4 de fevereiro de 2016 11:23:15 UTC-2, j verzani 
> escreveu:
>>
>> Then this should work where `u` is the Symbolic Function and eqn is 
>> just `diff(u(x),x) - 2u(x)`: `dsolve(eqn, ics=Dict(u(x0)=>y0))`, but it 
>> doesn't for me :( I think the problem is that initial conditions seem to 
>> only work with the power series method. For this problem this call will 
>> work with an initial condition: `dsolve(eqn, ics=Dict(u(x0)=>y0), 
>> hint="1st_power_series")`. Which isn't too satisfying, as there is an 
>> exact 
>> answer.
>>
>> --J
>>
>> On Thursday, February 4, 2016 at 7:47:14 AM UTC-5, 
>> jmarcell...@ufpi.edu.br wrote:
>>>
>>> Hi j verzani
>>>
>>>
>>>  SymPy documentation has the "ics", but does not show example: 
>>> dsolve(*eq*, *func=None*, *hint='default'*, *simplify=True*, 
>>> *ics=None*, *xi=None*, *eta=None*, *x0=0*, *n=6*, ***kwargs*)
>>> any tips?
>>>
>>> Em quinta-feira, 4 de fevereiro de 2016 02:01:20 UTC-2, j verzani 
>>> escreveu:

 There may be a better way, but here is one that works:

 * extract the RHS of the output: eqn = rhs(out)
 * find the symbol for C1 from the output of free_symbols(eqn)
 * if (x0,y0) are your initial conditions, then: solve(eqn(x=>x0) - 
 y0, C1)



 On Wednesday, February 3, 2016 at 10:43:30 PM UTC-5, 
 jmarcell...@ufpi.edu.br wrote:
>
> I want to solve an ode with initial conditions. For example
> using SymPy
> f   = SymFunction("f")
> x,y = Sym("x,y")
>
> edo1 = SymPy.diff(f(x),x) + x 
>
> SymPy.dsolve(edo1)
>
> f(x) == C1 - x^2/2
>
>
>
>
> How to solve C1?
>

[julia-users] Re: Solve ode with initial conditions

[jmarcellopereira]

Very good. I hope looking forward to the new version. Idea Code:

using SymPy

y   = SymFunction("y")
x   = Sym("x")

edo2 = SymPy.diff(y(x),x,x) - 4*y(x)-x

sol_simb_ord2 = SymPy.dsolve(edo2)

C1,C2 = Sym("C1,C2")

eq1 = sol_simb_ord2(y(x) => 1, x=> 0)

eq2 = SymPy.diff((sol_simb_ord2),x)(diff(y(x)) => 0, x=> 0)

coef = solve([eq1,eq2])

sol_geral = SymPy.subs(sol_simb_ord2,C1=>coef[C1],C2=>coef[C2])

g(x) = rhs(sol_geral)

g(x)


Em sexta-feira, 5 de fevereiro de 2016 16:14:00 UTC-2, j verzani escreveu:
>
> Similar things can be done. Rather than illustrate, I'll point out instead 
> that I just added an interface to `dsolve` that makes this much more 
> straightforward (
> https://github.com/jverzani/SymPy.jl/blob/master/src/dsolve.jl#L87). I'll 
> tag a new version soon.
>
> On Friday, February 5, 2016 at 8:18:36 AM UTC-5, jmarcell...@ufpi.edu.br 
> wrote:
>>
>> Hi j
>> very good,thanks! very practical. For a second order ode, as would be?
>>
>>
>> Em sexta-feira, 5 de fevereiro de 2016 01:50:34 UTC-2, j verzani escreveu:
>>>
>>> It can be a bit cleaner to just get the constant if you substitute as 
>>> the following:
>>>
>>> eqn = diff(u(x),x) - 2u(x)   # for example
>>> out = dsolve(eqn)
>>> solve(out(u(x) => y0, x=> x0))
>>>
>>> On Thursday, February 4, 2016 at 2:25:04 PM UTC-5, 
>>> jmarcell...@ufpi.edu.br wrote:

 Hi j
 in fact, the solution is not easy. I got your tip and made this way:

 C1 = Sym("C1")

 # eq1 na forma: substituir x por 0 na parte direita da sol_simb
 # e subtrair a expressao pelo valor de y0

 eq1 = subs(rhs(sol_simb),x=>0) - 1

 SymPy.solve(eq1,C1)




 Em quinta-feira, 4 de fevereiro de 2016 11:23:15 UTC-2, j verzani 
 escreveu:
>
> Then this should work where `u` is the Symbolic Function and eqn is 
> just `diff(u(x),x) - 2u(x)`: `dsolve(eqn, ics=Dict(u(x0)=>y0))`, but it 
> doesn't for me :( I think the problem is that initial conditions seem to 
> only work with the power series method. For this problem this call will 
> work with an initial condition: `dsolve(eqn, ics=Dict(u(x0)=>y0), 
> hint="1st_power_series")`. Which isn't too satisfying, as there is an 
> exact 
> answer.
>
> --J
>
> On Thursday, February 4, 2016 at 7:47:14 AM UTC-5, 
> jmarcell...@ufpi.edu.br wrote:
>>
>> Hi j verzani
>>
>>
>>  SymPy documentation has the "ics", but does not show example: dsolve
>> (*eq*, *func=None*, *hint='default'*, *simplify=True*, *ics=None*, 
>> *xi=None*, *eta=None*, *x0=0*, *n=6*, ***kwargs*)
>> any tips?
>>
>> Em quinta-feira, 4 de fevereiro de 2016 02:01:20 UTC-2, j verzani 
>> escreveu:
>>>
>>> There may be a better way, but here is one that works:
>>>
>>> * extract the RHS of the output: eqn = rhs(out)
>>> * find the symbol for C1 from the output of free_symbols(eqn)
>>> * if (x0,y0) are your initial conditions, then: solve(eqn(x=>x0) - 
>>> y0, C1)
>>>
>>>
>>>
>>> On Wednesday, February 3, 2016 at 10:43:30 PM UTC-5, 
>>> jmarcell...@ufpi.edu.br wrote:

 I want to solve an ode with initial conditions. For example
 using SymPy
 f   = SymFunction("f")
 x,y = Sym("x,y")

 edo1 = SymPy.diff(f(x),x) + x 

 SymPy.dsolve(edo1)

 f(x) == C1 - x^2/2




 How to solve C1?

>>>

[julia-users] associating outer constructors with different names with a type

[Uri Patish]

Hi,

I was wondering what is the best way going about the following issue. 
Suppose I have a type with few outer constructors which I name differently, 
and I want Julia to recognize these functions as constructors of that type. 
For example

type SomeType <: SomeAbstract
  name::ASCIIString
  value::Int
end

TypeA(value::Int) = SomeType("A", value)
TypeB(value::Int) = SomeType("B", value)

In this case, I have two pseudo-types, TypeA and TypeB, which have the same 
structure and are only different by their state. The problem with this 
approach is that now TypeA and TypeB are functions and not datatypes, thus, 
I cannot use operations defined on datetypes like checking for subtyping (TypeA 
<: SomeAbstract), or overloading type construction using call. 

Clearly, I could have defined two types which have exactly the same 
structure but this seems wrong to me as it involes code replication. 
Another possible solution is to define a macro which defines the type and 
its outer constructor, and I would call the macro to define TypeA and 
TypeB. Nonetheless, I was wondering if there was a way to tell Julia that 
the functions TypeA and TypeB are in fact constructors of SomeType. I'd be 
glag to hear about other solutions as well. 

Uri

[julia-users] Julia : install problem on ubuntu : Signing key not available

[Fred]

Hi,

When I install Julia on Xubuntu 15.10, I have some problems of 
authentication :

W: Erreur de GPG : http://ppa.launchpad.net wily InRelease : NO_PUBKEY 
CF979FFA3D3D3ACC

sudo apt-key adv --keyserver keyserver.ubuntu.com 
--recv-keys CF979FFA3D3D3ACC does not work

Trying to obtain the key 
from https://launchpad.net/~staticfloat/+archive/ubuntu/juliareleases does 
not work 

http://keyserver.ubuntu.com:11371/pks/lookup?fingerprint=on=index=0x770FD733195B3496F8F73CD4CF979FFA3D3D3ACC
 
does not work as well (blanc page)

So my question is : how to you manage to install Julia on Ubuntu without 
a GPG key problem ?

Thanks in advance !

Fred

Re: [julia-users] Re: how to undefine variable in composite types

[Andras Niedermayer]

class X(object):
@property 
def y(self):
try: return x.__y
except AttributeError: return "default value for y"

x = X()
print x.y

 



On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer wrote:
>
> The IPython autoreload extension does something quite similar to what has 
> been discussed here ( 
> https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ). 
> There are cases where it's actually very convenient, e.g. if you have 
> results from a long-running calculation in an IPython notebook interactive 
> session and you notice that you should change one of the classes, but don't 
> want to rerun the whole calculation.
>
> Some of this one gets almost for free in Julia with the Autoreload.jl 
> package, since methods are outside of types in Julia, so there's no need to 
> search for all object of a modified type in memory and add/modify the 
> methods like in Python. (Modifying inlined methods is a bit of a problem, 
> but one could probably extend Autoreload.jl to inject @noinline into 
> modules.)
>
> Adding fields would only be possible in Julia if it were possible to 
> overload field access ( https://github.com/JuliaLang/julia/issues/1974 ). 
>
> That's essentially the way one does this in Python. You add a property 
> getter y to class X, which allows you to access x.y:
>
> class X(object):
>
>
>
>
> On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:
>>
>> My main concern is predictability. 
>>
>> Imagine that I define a type Foo and start playing around with it - 
>> define some functions that work on foot, perhaps one or two types that hold 
>> foos, and manipulate a bunch of Foo instances.
>>
>> Then, I redefine the Foo type - say, I add a field. Which of the other 
>> things that I have defined are still valid?
>>
>> If I understand the motivation for this feature correctly, it's to make 
>> exploratory programming easier. However, I think it would actually make it 
>> a lot more difficult - it would basically give you a bazooka so heavy that 
>> the only thing you can reasonably aim at is your own foot... 
>>
>> //T 
>>
>>

Re: [julia-users] Pre-compiling images for different CPUs on GCloud

[Milan Bouchet-Valat]

Le jeudi 04 février 2016 à 17:17 -0800, Pavel a écrit :
> I am deploying a CPU-intensive application on Google Cloud Compute
> with Julia code running inside a Docker container. GCloud instances
> have a few different CPU architectures depending on the zone.
> Ideally, I would like to pre-compile Julia images (i.e. different
> docker container images) for all of those architectures.
> 
> Currently the following runs on container launch:
> 
>     include(joinpath(JULIA_HOME, Base.DATAROOTDIR, "julia",
> "build_sysimg.jl"))
>     build_sysimg(joinpath(dirname(Libdl.dlpath("libjulia")),"sys"),
> "native", "/home/juser/jimg.jl", force=true)
> 
> so that the "native" setting pre-compiles for the CPU that these
> commands are running on. That takes time and having that done at the
> container image build time would save cloud runtime.
> 
> Would it be possible to pre-compile for different CPUs on my
> development machine or do I need to run the pre-compilation on those
> exact CPUs? If the former is possible, what build_sysimg arguments
> would help? GCloud virtual machine architectures of interest include
> Sandy Bridge, Ivy Bridge, and Haswell CPU types.
You should be able to build images for older architectures on a machine
with a newer one, i.e. build images for Sandy Bridge and Ivy Bridge on
a Haswell machine. I don't think it would work in the other direction,
since some instructions wouldn't be supported and the code wouldn't
run.

So in your case you could replace "native" with "sandybridge",
"ivybridge", "haswell", or any value from the list printed by
llc -mattr=help.


Regards

Re: [julia-users] equivalent of python's string.title() in julia

[Milan Bouchet-Valat]

Le jeudi 04 février 2016 à 17:31 -0800, julialangfans...@gmail.com a
écrit :
> in python, "abc def ghi jkl".title() capitalizes each "word" in the
> string, giving 'Abc Def Ghi Jkl' as the result
> 
> i have not been able to find a similar string function in julia, so
> i'm currently doing this:
> 
> julia> join(map(ucfirst, split("abc def ghi jkl")), " ")
> "Abc Def Ghi Jkl"
> 
> is there a better / more straightforward julia-based solution?
I wouldn't call it "straightforward", but if you need a Unicode-correct 
way of applying title case, you can use UnicodeExtras, which relies on
ICU:
https://github.com/nolta/UnicodeExtras.jl#case-handling

Title case hasn't been implemented in base yet, though it's been
mentioned in the past:
https://github.com/JuliaLang/julia/issues/11471
https://github.com/JuliaLang/julia/issues/774


Regards

Re: [julia-users] Memory allocation free array slices ?

[Tim Holy]

I imagine this will be possible some day, but I can't predict when.

Currently, if your slices are contiguous (step size 1 in each range), there is 
in fact another option: encode the slice with a CartesianRange. See 
http://julialang.org/blog/2016/02/iteration/

Example:

julia> function foo(A, R)
   s = zero(eltype(A))
   for I in R
   s += A[I]
   end
   s
   end
foo (generic function with 1 method)

julia> function bar(A)
   s = zero(eltype(A))
   for j = 1:size(A,2)
   s += foo(A, CartesianRange(CartesianIndex((1,j)), 
CartesianIndex((size(A,1),j
   end
   s
   end
bar (generic function with 1 method)

julia> A = rand(4,10^4);

julia> bar(A)
20026.547698847495

julia> @time 1
  0.08 seconds (148 allocations: 10.151 KB)
1

julia> @time bar
  0.01 seconds (3 allocations: 144 bytes)
bar (generic function with 1 method)


Look ma, no allocation!

--Tim


On Thursday, February 04, 2016 07:09:45 PM Nitin Arora wrote:
> Hello,
> 
> I realize that the current best way to do array slices is to either use
> ArrayViews or SubArrays.
> 
> But will it ever be possible (in future) to have slice of contiguous arrays
> without memory allocation ? How do other compiled languages like Fortran or
> C deal with this issue ?
> 
> For example, given:
> M1 = rand(7,3)
> M = view(M1,1:6,1:3) # some memory allocation occurs here
> a= rand(3)
> c1 = zeros(6)
> c =view(c1) # some memory allocation occurs here
> 
> would it be possible to do this step without array allocation in future ?
> c = M*a # 2 memory allocations
> 
> I don't have enough of a background to know the limits of the array
> indexing/slicing algorithms. I am designing an optimization software in
> Julia and I am happy using ArrayViews for now but just wanted to know what
> can be expected in the future.
> 
> thanks,
> Nitin

Re: [julia-users] Re: how to undefine variable in composite types

[Andras Niedermayer]

The IPython autoreload extension does something quite similar to what has 
been discussed here ( 
https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ). 
There are cases where it's actually very convenient, e.g. if you have 
results from a long-running calculation in an IPython notebook interactive 
session and you notice that you should change one of the classes, but don't 
want to rerun the whole calculation.

Some of this one gets almost for free in Julia with the Autoreload.jl 
package, since methods are outside of types in Julia, so there's no need to 
search for all object of a modified type in memory and add/modify the 
methods like in Python. (Modifying inlined methods is a bit of a problem, 
but one could probably extend Autoreload.jl to inject @noinline into 
modules.)

Adding fields would only be possible in Julia if it were possible to 
overload field access ( https://github.com/JuliaLang/julia/issues/1974 ). 

That's essentially the way one does this in Python. You add a property 
getter y to class X, which allows you to access x.y:

class X(object):




On Friday, February 5, 2016 at 8:17:47 AM UTC+1, Tomas Lycken wrote:
>
> My main concern is predictability. 
>
> Imagine that I define a type Foo and start playing around with it - define 
> some functions that work on foot, perhaps one or two types that hold foos, 
> and manipulate a bunch of Foo instances.
>
> Then, I redefine the Foo type - say, I add a field. Which of the other 
> things that I have defined are still valid?
>
> If I understand the motivation for this feature correctly, it's to make 
> exploratory programming easier. However, I think it would actually make it 
> a lot more difficult - it would basically give you a bazooka so heavy that 
> the only thing you can reasonably aim at is your own foot... 
>
> //T 
>
>

Re: [julia-users] Re: Conda

[Luthaf]

> When I do not have Conda installed but install PyCall in Julia does 
Pkg.add("PyCall") still installs its own small PYthon distribution?


As far as I know, if there is no PYTHON environnement variable and no 
`python` in path, then the automatic MiniConda Python installation is used.


> Small? Mine (that I didn't ask for) has 320 Mb.

Yes, it is small for a scientific Python distribution. The fulll 
Anaconda installer is 1.2G. The standard Python installation is 78M, 
which is smaller, and you can install it first if you want to use it 
instead of Conda installation. But the standard Python do not have 
numpy/scipy/... and they are a pain to install on Windows.


--
Luthaf

[julia-users] Re: Solve ode with initial conditions

[jmarcellopereira]

Hi j
very good,thanks! very practical. For a second order ode, as would be?


Em sexta-feira, 5 de fevereiro de 2016 01:50:34 UTC-2, j verzani escreveu:
>
> It can be a bit cleaner to just get the constant if you substitute as the 
> following:
>
> eqn = diff(u(x),x) - 2u(x)   # for example
> out = dsolve(eqn)
> solve(out(u(x) => y0, x=> x0))
>
> On Thursday, February 4, 2016 at 2:25:04 PM UTC-5, jmarcell...@ufpi.edu.br 
> wrote:
>>
>> Hi j
>> in fact, the solution is not easy. I got your tip and made this way:
>>
>> C1 = Sym("C1")
>>
>> # eq1 na forma: substituir x por 0 na parte direita da sol_simb
>> # e subtrair a expressao pelo valor de y0
>>
>> eq1 = subs(rhs(sol_simb),x=>0) - 1
>>
>> SymPy.solve(eq1,C1)
>>
>>
>>
>>
>> Em quinta-feira, 4 de fevereiro de 2016 11:23:15 UTC-2, j verzani 
>> escreveu:
>>>
>>> Then this should work where `u` is the Symbolic Function and eqn is just 
>>> `diff(u(x),x) - 2u(x)`: `dsolve(eqn, ics=Dict(u(x0)=>y0))`, but it doesn't 
>>> for me :( I think the problem is that initial conditions seem to only work 
>>> with the power series method. For this problem this call will work with an 
>>> initial condition: `dsolve(eqn, ics=Dict(u(x0)=>y0), 
>>> hint="1st_power_series")`. Which isn't too satisfying, as there is an exact 
>>> answer.
>>>
>>> --J
>>>
>>> On Thursday, February 4, 2016 at 7:47:14 AM UTC-5, 
>>> jmarcell...@ufpi.edu.br wrote:

 Hi j verzani


  SymPy documentation has the "ics", but does not show example: dsolve(
 *eq*, *func=None*, *hint='default'*, *simplify=True*, *ics=None*, 
 *xi=None*, *eta=None*, *x0=0*, *n=6*, ***kwargs*)
 any tips?

 Em quinta-feira, 4 de fevereiro de 2016 02:01:20 UTC-2, j verzani 
 escreveu:
>
> There may be a better way, but here is one that works:
>
> * extract the RHS of the output: eqn = rhs(out)
> * find the symbol for C1 from the output of free_symbols(eqn)
> * if (x0,y0) are your initial conditions, then: solve(eqn(x=>x0) - y0, 
> C1)
>
>
>
> On Wednesday, February 3, 2016 at 10:43:30 PM UTC-5, 
> jmarcell...@ufpi.edu.br wrote:
>>
>> I want to solve an ode with initial conditions. For example
>> using SymPy
>> f   = SymFunction("f")
>> x,y = Sym("x,y")
>>
>> edo1 = SymPy.diff(f(x),x) + x 
>>
>> SymPy.dsolve(edo1)
>>
>> f(x) == C1 - x^2/2
>>
>>
>>
>>
>> How to solve C1?
>>
>

[julia-users] Re: citing Julia

[Sisyphuss]

Large packages often offer this information in their Github "readme.md"


On Friday, February 5, 2016 at 7:58:39 AM UTC+1, kleinsplash wrote:
>
> How about citing a specific package? 
>
> On Wednesday, 17 July 2013 03:13:24 UTC+2, georgiana wrote:
>>
>> Is there a suggested way to cite Julia if used for a publication?
>>  
>> Georgiana
>>
>

Re: [julia-users] Pre-compiling images for different CPUs on GCloud

[Pavel]

I tried this approach using a local machine with
product: Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
which in my understanding belongs to the "haswell" type.

setting
build_sysimg(joinpath(dirname(Libdl.dlpath("libjulia")),"sys"), 
"haswell", "/home/juser/jimg.jl", force=true)

resulted in 
'haswell' is not a recognized processor for this target (ignoring 
processor)

On the other hand, setting "native" instead, after deploying on GCloud 
haswell-zone says that the image was precompiled for a different 
architecture.


On Friday, February 5, 2016 at 1:01:37 AM UTC-8, Milan Bouchet-Valat wrote:
>
> Le jeudi 04 février 2016 à 17:17 -0800, Pavel a écrit : 
> > I am deploying a CPU-intensive application on Google Cloud Compute 
> > with Julia code running inside a Docker container. GCloud instances 
> > have a few different CPU architectures depending on the zone. 
> > Ideally, I would like to pre-compile Julia images (i.e. different 
> > docker container images) for all of those architectures. 
> > 
> > Currently the following runs on container launch: 
> > 
> > include(joinpath(JULIA_HOME, Base.DATAROOTDIR, "julia", 
> > "build_sysimg.jl")) 
> > build_sysimg(joinpath(dirname(Libdl.dlpath("libjulia")),"sys"), 
> > "native", "/home/juser/jimg.jl", force=true) 
> > 
> > so that the "native" setting pre-compiles for the CPU that these 
> > commands are running on. That takes time and having that done at the 
> > container image build time would save cloud runtime. 
> > 
> > Would it be possible to pre-compile for different CPUs on my 
> > development machine or do I need to run the pre-compilation on those 
> > exact CPUs? If the former is possible, what build_sysimg arguments 
> > would help? GCloud virtual machine architectures of interest include 
> > Sandy Bridge, Ivy Bridge, and Haswell CPU types. 
> You should be able to build images for older architectures on a machine 
> with a newer one, i.e. build images for Sandy Bridge and Ivy Bridge on 
> a Haswell machine. I don't think it would work in the other direction, 
> since some instructions wouldn't be supported and the code wouldn't 
> run. 
>
> So in your case you could replace "native" with "sandybridge", 
> "ivybridge", "haswell", or any value from the list printed by 
> llc -mattr=help. 
>
>
> Regards 
>

[julia-users] Re: Shell mode for scripts

[Páll Haraldsson]

I'm not sure I get what you mean. E.g.:

julia> run(`ls`)

does the same for me as:

shell> ls


Note the shell, isn't actually a shell.. and not exactly the same as run. 
Maybe they are close enough, is is it bothering you? E.g. I couldn't run 
two shell commands this way:

julia> run(`ls;ls`)

run(`ls;ls`)
ERROR: could not spawn `ls;ls`: no such file or directory (ENOENT)
 in _jl_spawn at process.jl:262
 in anonymous at process.jl:415
 in setup_stdio at ./process.jl:403
 in __spawn#58__ at ./process.jl:414
 in run at ./process.jl:530

shell> ls;ls

shell> env

[does what I expect, include list HOME]

shell> echo $HOME
ERROR: UndefVarError: HOME not defined

[I'm on Linux, with Julia 4.0 here.]

-- 
Palli.

On Tuesday, February 2, 2016 at 1:44:33 PM UTC, Lance Larsen wrote:
>
> In the julia interactive interpreter, the shell mode is very nice. I would 
> like to be able to use julia as my main shell except for one thing. Shell 
> mode is only available in interactive mode. Has there been discussion about 
> having a way to enter shell mode in julia scripts. That would be awesome!
>

Re: [julia-users] Memory allocation free array slices ?

[Nitin Arora]

Thanks Tim, this is very useful. I will probably use CartesianRange now. 

Is Julia 0.5 Arraypocalypse planning to address this issue as well ?

thanks,
Nitin

On Friday, February 5, 2016 at 3:24:34 PM UTC-8, Tim Holy wrote:
>
> On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote: 
> > I think this needs to be @time bar(A). 
>
> Yeah, sorry for the typo. 
>
> > I get 
> > 
> > julia> @time bar(A) 
> >   0.000269 seconds (5 allocations: 176 bytes) 
> > 20010.937886591404 
>
> That's just REPL allocation. Since A has 1 columns, if this strategy 
> were 
> allocating you'd expect "1+n allocations," where n comes from the 
> REPL. 
>
> --Tim 
>
>

[julia-users] WARNING: replacing module ...

[Gabriel Mihalache]

Hello, all!
I must be doing something wrong. Say I have the following code in a file 
called myMod.jl


module myMod

using NLopt

function compute()
  ...
  pmap(...)
  ...
end

end

and then in a console I do

addprocs()
@everywhere include("myMod.jl")
myMod.compute()

I get a bunch of warnings, one per worker, complaining that the module 
NLopt is being replaced. This seems harmless in practice, but it's hinting 
that I'm doing something wrong.

What's the proper way to do this? (Let all workers know about my module and 
the packages it's using.) I'm on 0.4.3

Thank you!