Re: [julia-users] Cannot pull with rebase...?

[Tony Kelman]

Mostly the latter, that contains source which is what git is complaining 
about here. The former, the .julia\lib\v0.4 directory, will contain only 
precompiled .ji files, which are binaries and Julia will overwrite those 
when needed.

On Wednesday, February 17, 2016 at 9:16:22 PM UTC-8, Hua Chai wrote:
>
> I had the same problem. Do you mean deleting the "v0.4" folder 
> under C:\Users\Hua\.julia\lib or the C:\Users\Hua\.julia\v0.4 folder?
>
> On Wednesday, February 3, 2016 at 8:39:52 PM UTC-5, Joshua Duncan wrote:
>>
>> If anyone is interested, just deleting your v0.4 library folder and then 
>> running Pkg.update() will fix this problem.
>>
>> On Friday, January 29, 2016 at 7:45:26 PM UTC-6, Joshua Duncan wrote:
>>>
>>> Have you resolved this problem?  I have the same errors as you.  Just 
>>> installed v0.4.3 on Windows 10.
>>>
>>> Thanks,
>>> Josh
>>>
>>> On Friday, January 15, 2016 at 8:54:42 AM UTC-6, fab...@chalmers.se 
>>> wrote:

 "Pkg.dir()" give the same "Cannot pull with rebase..." error message.

 Thanks.

 On Wednesday, January 13, 2016 at 5:12:37 PM UTC+1, Stefan Karpinski 
 wrote:
>
> What is the result of `Pkg.dir()`  in the Julia REPL? That's where 
> your packages live and the METADATA repo.
>
> On Wed, Jan 13, 2016 at 10:36 AM,  wrote:
>
>> Thanks for the reply. Unfortunately, I cannot find any such folder. 
>> This is the binary 64-bit version of Julia 0.4.2 on W10x64pro. I 
>> expected 
>> this to just install and run, but apparently this is not the case, at 
>> least 
>> not on W10...
>>
>>
>> On Tuesday, January 12, 2016 at 4:48:22 PM UTC+1, Stefan Karpinski 
>> wrote:
>>>
>>> If you go into ~/.julia/v0.4/METADATA and do `git status` you should 
>>> see what's going on there.
>>>
>>> On Tue, Jan 12, 2016 at 10:41 AM,  wrote:
>>>
 Hello all 
 (first post)

 I just now downloaded version 0.4.2 of Julia, and installed it on 
 my W10x64pro machine. I was going to use it to run the optimization 
 packages, so I did the Pkg.update() on the Julia cmd line, as 
 instructed 
 here http://www.juliaopt.org/.

 To my surprise, i get the following error message:

 INFO: Updating METADATA...
 error: Cannot pull with rebase: You have unstaged changes.
 ERROR: failed process: Process(`git pull --rebase -q`, 
 ProcessExited(1)) [1]
  in pipeline_error at process.jl:555

 I have not done any changes to any source, just DL'ed and installed 
 the 64-bit binary for windows, and I have no clue what is going on... 
 Does 
 anyone have any ideas?

 Thanks.

>>>
>>>
>

[julia-users] Re: Unitful.jl for physical units

[Eric Forgy]

This is cool (Unitful.jl and SIUnits.jl). I imagine similar work can be 
done for currencies?

[julia-users] Bug #15077 still present

[Scott Jones]

I just wanted to warn people that the bug in #15077 is still present, there 
is a small bug in the change #15096 that Jeff merged yesterday.
Line 536 of dict.jl:
if index - index0 > maxprobe
should be 
if ((index - index0) & (newsz - 1)) > maxprobe
instead, to correctly handle wrapping around the end of the hash table.

Since I am no longer able to submit a PR to fix this, hopefully somebody 
else can shortly.
Thanks, Scott

Re: [julia-users] Cannot pull with rebase...?

[Hua Chai]

I had the same problem. Do you mean deleting the "v0.4" folder 
under C:\Users\Hua\.julia\lib or the C:\Users\Hua\.julia\v0.4 folder?

On Wednesday, February 3, 2016 at 8:39:52 PM UTC-5, Joshua Duncan wrote:
>
> If anyone is interested, just deleting your v0.4 library folder and then 
> running Pkg.update() will fix this problem.
>
> On Friday, January 29, 2016 at 7:45:26 PM UTC-6, Joshua Duncan wrote:
>>
>> Have you resolved this problem?  I have the same errors as you.  Just 
>> installed v0.4.3 on Windows 10.
>>
>> Thanks,
>> Josh
>>
>> On Friday, January 15, 2016 at 8:54:42 AM UTC-6, fab...@chalmers.se 
>> wrote:
>>>
>>> "Pkg.dir()" give the same "Cannot pull with rebase..." error message.
>>>
>>> Thanks.
>>>
>>> On Wednesday, January 13, 2016 at 5:12:37 PM UTC+1, Stefan Karpinski 
>>> wrote:

 What is the result of `Pkg.dir()`  in the Julia REPL? That's where your 
 packages live and the METADATA repo.

 On Wed, Jan 13, 2016 at 10:36 AM,  wrote:

> Thanks for the reply. Unfortunately, I cannot find any such folder. 
> This is the binary 64-bit version of Julia 0.4.2 on W10x64pro. I expected 
> this to just install and run, but apparently this is not the case, at 
> least 
> not on W10...
>
>
> On Tuesday, January 12, 2016 at 4:48:22 PM UTC+1, Stefan Karpinski 
> wrote:
>>
>> If you go into ~/.julia/v0.4/METADATA and do `git status` you should 
>> see what's going on there.
>>
>> On Tue, Jan 12, 2016 at 10:41 AM,  wrote:
>>
>>> Hello all 
>>> (first post)
>>>
>>> I just now downloaded version 0.4.2 of Julia, and installed it on my 
>>> W10x64pro machine. I was going to use it to run the optimization 
>>> packages, 
>>> so I did the Pkg.update() on the Julia cmd line, as instructed here 
>>> http://www.juliaopt.org/.
>>>
>>> To my surprise, i get the following error message:
>>>
>>> INFO: Updating METADATA...
>>> error: Cannot pull with rebase: You have unstaged changes.
>>> ERROR: failed process: Process(`git pull --rebase -q`, 
>>> ProcessExited(1)) [1]
>>>  in pipeline_error at process.jl:555
>>>
>>> I have not done any changes to any source, just DL'ed and installed 
>>> the 64-bit binary for windows, and I have no clue what is going on... 
>>> Does 
>>> anyone have any ideas?
>>>
>>> Thanks.
>>>
>>
>>

[julia-users] Reading one field from a file

[Victor Liu]

I have a text file of the following format:

--- snip ---
Nx Ny
dx dy

v(x1,y1)
v(x2,y2)
...
v(xNx,y1)
v(x1,y2)
...
v(xNx,yNy)
--- snip ---

In C, I would normally use fscanf to read in the four fields at the top 
first, then loop through and read in the rest.
What is the idiomatic way of achieving the same thing in Julia? I would 
like the list of numbers to end up in a matrix of the proper size.
As far as I can tell, there's no simple way of reading only one textual 
field from a file at a time.

[julia-users] Re: Unitful.jl for physical units

[Scott Jones]

Is there anything to convert to/from Julia's UT seconds (which are tied to 
the Earth's rotation), and SI seconds?

On Friday, February 12, 2016 at 3:23:22 PM UTC-5, Andrew Keller wrote:
>
> I'm happy to share a package I wrote for using physical units in Julia, 
> Unitful.jl . Much credit 
> and gratitude is due to Keno Fischer for the SIUnits.jl 
>  package which served as my 
> inspiration. This is a work in progress, but I think perhaps a serviceable 
> one depending on what you're doing. 
>
> Like SIUnits.jl, this package encodes units in the type signature to avoid 
> run-time performance penalties. From there, the implementations diverge. 
> The package is targeted to Julia 0.5 / master, as there are some 
> limitations with how promote_op is used in Julia 0.4 (#13803) 
> . I decided it wasn't 
> worth targeting 0.4 if the behavior would be inconsistent. 
>
> Some highlights include:
>
>- Non-SI units are treated on the same footing as SI units, with only 
>a few exceptions (unit conversion method). Use whatever weird units 
>you want.
>- Support for units like micron / (meter Kelvin), where some of the 
>units could cancel out but you don't necessarily want them to.
>- Support for LinSpace and other Range types. Probably there are still 
>some glitches to be found, though.
>- Support for rational exponents of units.
>- Some tests (see these for usage examples).
>
> Please see the documentation for a comprehensive discussion, including 
> issues / to do list, as well as how to add your own units, etc.
> Comments and feedback are welcome.
>
> Best,
> Andrew Keller
>

[julia-users] Pkg.update() fails after installation

[Hua Chai]

I just installed the Julia+Juno bundle (downloaded from Julialang.org) and 
ran the following code:

Pkg.status()
Pkg.update()

and the result is "failed process: Process(git pull --rebase -q, 
ProcessExited(1))[1] in pipeline_error at process.jl:555", while the 
console shows "error: Cannot pull with rebase: You have unstaged changes."

Does anyone know what this is all about and what should I do? Thanks!

RE: Private message regarding: [julia-users] Cannot pull with rebase...?

[Tony Kelman]

Yes but a general question like this should be asked on the mailing list, 
please don't contact people directly for things that can be public.

You can either use the Julia REPL's shell mode (hit semicolon), or you can run 
git-bash from a separate Git installation. In Julia 0.4 we include a Git 
installation within the Julia binaries on Windows and Mac but this will not 
always be the case. If you're on Windows, navigate to where you have Julia 
installed (the variable JULIA_HOME in the Julia REPL will tell you where that 
is), then under the Git/ directory, run git-bash.exe. You can navigate around 
your METADATA folder and anywhere else in that prompt, and run git commands 
from there.


> Date: Wed, 17 Feb 2016 20:59:11 -0800 
> From: kenhc...@gmail.com 
> To: t...@kelman.net 
> Subject: Private message regarding: [julia-users] Cannot pull with rebase...? 
>  
> May I ask where and how do you run commands like 'git diff'? 
>  
> On Sunday, January 17, 2016 at 5:23:25 PM UTC-5, Tony Kelman wrote: 
> That doesn't make much sense... 
>  
> How about ENV["HOMEPATH"] ? 
> That should tell you where your pkg folder is. Find  
> .julia/v0.4/METADATA there and run `git diff` to see what the local  
> changes are. If you don't remember making them you can probably do `git  
> checkout -- filename` to undo all of them. 
  

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

However it can't work in such a  case:

module X
  export f
   g(x) = 2x
   function f(x)
   (current_module()).g(x)
   end
end

module Y
   using X
   export h
   g(x) = 4x
   h(x) = f(x)
end


module Z
  using Y
  println(h(4))
end

On Wed, Feb 17, 2016 at 5:37 PM, Julia Tylors  wrote:

> Yes,
> this worked too, Thank you.!
>
> julia> module X
>   export f
>g(x) = 2x
>function f(x)
>(current_module()).g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) = 4x
>println(f(4))
>end
> 16
> Y
>
> julia> module Z
>using X
>g(x) = 5x
>println(f(4))
>end
> 20
> Z
>
> On Wed, Feb 17, 2016 at 4:44 PM, Lutfullah Tomak 
> wrote:
>
>> Hi
>> Will this achieve what you want?
>>
>> module Z
>> g()=println("Z.g")
>> function h()
>> (current_module()).g()
>> end
>> end
>> module X
>> using Z
>> g()=println("X.g")
>> function f()
>> Z.h()
>> (current_module()).g()
>> end
>> end
>> module Y
>> using X
>> g()=println("Y.g")
>> X.f()
>> end
>>
>> using Y
>>
>> It prints Y.g twice. Or do you want h() to use X's g()?
>
>
>

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

Yes,
this worked too, Thank you.!

julia> module X
  export f
   g(x) = 2x
   function f(x)
   (current_module()).g(x)
   end
   end
X

julia> module Y
   using X
   g(x) = 4x
   println(f(4))
   end
16
Y

julia> module Z
   using X
   g(x) = 5x
   println(f(4))
   end
20
Z

On Wed, Feb 17, 2016 at 4:44 PM, Lutfullah Tomak 
wrote:

> Hi
> Will this achieve what you want?
>
> module Z
> g()=println("Z.g")
> function h()
> (current_module()).g()
> end
> end
> module X
> using Z
> g()=println("X.g")
> function f()
> Z.h()
> (current_module()).g()
> end
> end
> module Y
> using X
> g()=println("Y.g")
> X.f()
> end
>
> using Y
>
> It prints Y.g twice. Or do you want h() to use X's g()?

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

This gave me an idea,
i would define a function with dynamically scope-able only with 2 level
depth.
and create a macro such as @patchable to mark that function, after dispatch
from there.
That shouldn't be too hard.
Thanks

On Wed, Feb 17, 2016 at 3:24 PM, Stefan Karpinski 
wrote:

> Yes, that can be sort of a pain. Our I/O functions all have this issue –
> you have to pass the IO object through all the way down the call stack. The
> alternative is to do some kind of dynamic scoping, which we don't have
> language support for, so you'd have to do it manually. I.e. something like
> this:
>
> module X
> export f, g
> const h = Function[]
> f(x) = 2g(x)
> g(x) = 3h[end](x)
> end
>
> module Y
> using X
> function f(x)
> push!(X.h, x->5x)
> y = X.f(x)
> pop!(X.h)
> return y
> end
> end
>
> julia> Y.f(7)
> 210
>
>
>
> On Wed, Feb 17, 2016 at 5:40 PM, Julia Tylors 
> wrote:
>
>> Thanks Stephen.
>> than i will go by passing g as a parameter to f, but that will make me
>> pass g down to all other functions needing g along the way in the call
>> stack of f.
>>
>> Thanks again.
>>
>> On Wednesday, February 17, 2016 at 2:32:16 PM UTC-8, Stefan Karpinski
>> wrote:
>>>
>>> The behavior of a function does not depend on where it is called from,
>>> that's a basic principle of the language and one that we are not going to
>>> change. So I think the bottom line is that by design there is no way to do
>>> what you're trying to do.
>>>
>>> On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors 
>>> wrote:
>>>
 basically you generate the code every time  in the module of interest.
 but in my case, the function f is very huge and i don't want to generate it
 all the time.
 so that is not what i want to do either. I have seen that already. That
 is why i was asking "is there  some sort of a special AST node, which
 resolves the function based on the current scope the code."

 that would be a lot more helpful.
 Thanks


 On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
 wrote:
>
> module X
> export @make_f
> macro make_f()
> :($(esc(:f))(x) = $(esc(:g))(x))
> end
> end
>
> module Y
> using X
> g(x) = 3x
> @make_f
> end
>
> julia> Y.f(2)
> 6
>
> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors 
> wrote:
>
>> Yes, exactly.
>>
>>
>> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
>> wrote:
>>>
>>> So you want to have a macro that defines f for you in Y such that it
>>> calls Y's g?
>>>
>>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
>>> wrote:
>>>
 I know, but would it be possible to generate code in module X,
 using g as a globally defined function so that the function g gets 
 resolved
 based on the module where f is being used?

 Ps: I don't want to pass g as a parameter to f.

 Here is an example:

 julia> module X
   export f
   g(x) = 2x
   f(x) = g(x)
   end
 X

 julia> module Y
   using X
   g(x) = 3x
   println(f(4))
   end
 8 *# this should have been 12 if the function g is used from Y, it
 hasn't been used because when we look at the AST, we would see it is 
 making
 a call to the function g in module X.*
 Y

 julia> f.env.defs.func.code
 AST(:($(Expr(:lambda, Any[:x],
 Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], :(begin  # none, line 4:
 *return (X.g)(x) # here*
 end)

 So in the light of this, is it possible to generate code using a
 macro with some sort of a special AST node, which resolves the function
 based on the current scope the code.



 On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan
 Karpinski wrote:
>
> There is no g defined inside of module X.
>
> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
> wrote:
>
>> julia> module X
>>export f
>>function f(x)
>>g(x)
>>end
>>end
>> X
>>
>> julia> module Y
>>using X
>>g(x) =  2x
>>f(4)
>>end
>> ERROR: UndefVarError: g not defined
>>  in f at ./none:4
>>
>> I am trying to use another function 

Re: [julia-users] Weird Hygiene Issue

[Lutfullah Tomak]

Hi
Will this achieve what you want?

module Z
g()=println("Z.g")
function h()
(current_module()).g()
end
end
module X
using Z
g()=println("X.g")
function f()
Z.h()
(current_module()).g()
end
end
module Y
using X
g()=println("Y.g")
X.f()
end

using Y

It prints Y.g twice. Or do you want h() to use X's g()?

Re: [julia-users] Re: Weird Hygiene Issue

[Stefan Karpinski]

Yep, that's a much nicer way to do this. Note that with the new
higher-order functions work, Foo.f will probably be specialized for each
individual g, so if you're worried about code generation, this doesn't
really help. But then again, it's hard to imagine a function being called
from so many other modules that code generation becomes a huge problem.
Generally anything that is O(loc) is not a big issue.

On Wed, Feb 17, 2016 at 6:45 PM, Greg Plowman 
wrote:

>
> Not sure if this is helpful:
>
> module Foo
> f(g,x) = g(x)
> end
>
> module X
> using Foo
> g(x) = 2x
> f(x) = Foo.f(g,x)
> end
>
> module Y
> using Foo
> g(x) = 3x
> f(x) = Foo.f(g,x)
> end
>
> X.f(4)
> Y.f(4)
>
>

[julia-users] Re: julia on ARM for a drone

[Jeff Waller]

You know it's kind of a feeling right now + 1 specific thing and + planned 
thing.

The grand idea is. I want to imbue a drone with AI, which in general 
requires an implementation and a community and Julia is a good pick. 
 Latency is a possible problem.
Right now the hardware is not super fast but maybe not for long 
. 
 Not entirely new, but a better approach.

Currently, I'm using Kalman filters 
 for a better GPS 
estimation, and in the future, maybe constrained optimization for 
determining the best location to navigate to best video angle.

[julia-users] Re: Weird Hygiene Issue

[Greg Plowman]

Not sure if this is helpful:

module Foo
f(g,x) = g(x)
end

module X
using Foo
g(x) = 2x
f(x) = Foo.f(g,x)
end

module Y
using Foo
g(x) = 3x
f(x) = Foo.f(g,x)
end

X.f(4)
Y.f(4)

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

On the topic of I/O, we used to have this kind of dynamic scoping behavior
for the current output stream, but it's a performance nightmare and we bit
the bullet at some point and went ahead and threaded the IO argument
through all the functions. No regrets. It's faster, clearer, more explicit.

On Wed, Feb 17, 2016 at 6:24 PM, Stefan Karpinski 
wrote:

> Yes, that can be sort of a pain. Our I/O functions all have this issue –
> you have to pass the IO object through all the way down the call stack. The
> alternative is to do some kind of dynamic scoping, which we don't have
> language support for, so you'd have to do it manually. I.e. something like
> this:
>
> module X
> export f, g
> const h = Function[]
> f(x) = 2g(x)
> g(x) = 3h[end](x)
> end
>
> module Y
> using X
> function f(x)
> push!(X.h, x->5x)
> y = X.f(x)
> pop!(X.h)
> return y
> end
> end
>
> julia> Y.f(7)
> 210
>
>
>
> On Wed, Feb 17, 2016 at 5:40 PM, Julia Tylors 
> wrote:
>
>> Thanks Stephen.
>> than i will go by passing g as a parameter to f, but that will make me
>> pass g down to all other functions needing g along the way in the call
>> stack of f.
>>
>> Thanks again.
>>
>> On Wednesday, February 17, 2016 at 2:32:16 PM UTC-8, Stefan Karpinski
>> wrote:
>>>
>>> The behavior of a function does not depend on where it is called from,
>>> that's a basic principle of the language and one that we are not going to
>>> change. So I think the bottom line is that by design there is no way to do
>>> what you're trying to do.
>>>
>>> On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors 
>>> wrote:
>>>
 basically you generate the code every time  in the module of interest.
 but in my case, the function f is very huge and i don't want to generate it
 all the time.
 so that is not what i want to do either. I have seen that already. That
 is why i was asking "is there  some sort of a special AST node, which
 resolves the function based on the current scope the code."

 that would be a lot more helpful.
 Thanks


 On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
 wrote:
>
> module X
> export @make_f
> macro make_f()
> :($(esc(:f))(x) = $(esc(:g))(x))
> end
> end
>
> module Y
> using X
> g(x) = 3x
> @make_f
> end
>
> julia> Y.f(2)
> 6
>
> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors 
> wrote:
>
>> Yes, exactly.
>>
>>
>> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
>> wrote:
>>>
>>> So you want to have a macro that defines f for you in Y such that it
>>> calls Y's g?
>>>
>>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
>>> wrote:
>>>
 I know, but would it be possible to generate code in module X,
 using g as a globally defined function so that the function g gets 
 resolved
 based on the module where f is being used?

 Ps: I don't want to pass g as a parameter to f.

 Here is an example:

 julia> module X
   export f
   g(x) = 2x
   f(x) = g(x)
   end
 X

 julia> module Y
   using X
   g(x) = 3x
   println(f(4))
   end
 8 *# this should have been 12 if the function g is used from Y, it
 hasn't been used because when we look at the AST, we would see it is 
 making
 a call to the function g in module X.*
 Y

 julia> f.env.defs.func.code
 AST(:($(Expr(:lambda, Any[:x],
 Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], :(begin  # none, line 4:
 *return (X.g)(x) # here*
 end)

 So in the light of this, is it possible to generate code using a
 macro with some sort of a special AST node, which resolves the function
 based on the current scope the code.



 On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan
 Karpinski wrote:
>
> There is no g defined inside of module X.
>
> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
> wrote:
>
>> julia> module X
>>export f
>>function f(x)
>>g(x)
>>end
>>end
>> X
>>
>> julia> module Y
>>using X
>>g(x) =  2x
>>f(4)
>>end
>> ERROR: UndefVarError: g not defined
>>  in f 

Re: [julia-users] Re: Unitful.jl for physical units

[Jake Rosoman]

Its always the former. I hadn't thought about using proportions. Is that idea
related to the idea of delta units which I have seen discussed in the Unitful
issue tracker.

> On Feb 18 2016, at 11:29 am, Jeffrey Sarnoff
jeffrey.sarn...@gmail.com wrote:  

>

> In this unit-land, is length always quantity * unit_of_length? or also may
it be proportion * reference_distance (1/4 of the current line length)?

>

> Or -- shall we seek an avenue that somehow is both without being either?  
  
On Wednesday, February 17, 2016 at 5:10:15 PM UTC-5, Jake Rosoman wrote:

>

>> Oops thanks for being patient. By "this" I meant "dispatch on abstract
units/dimensions". The motivation is to be able to write a function which
takes a length without caring what the specific unit of that length is. Be it
feet or cm etc. This is to make the intent of the function clearer and enable
polymorphism. For example:  
  
direction = 0radians  
move(r::Angle) = direction += r  
move(l::Length) = translate(direction, l)  
  
Also speed could be defined as Ratio{d:size, t:time}. Which would be
hard to do using unitful as is  

>>

>> On Thu, 18 Feb 2016 at 10:25 AM Jeffrey Sarnoff
jeffrey...@gmail.com wrote:  

>>

>>> Jake,

>>>

>>>  

>>>

>>> It would be helpful to know more clearly what is the "this" that you are
experimenting with "ways to achieve this"?  
>>>

>>> I took a glance at your code, and one thing that is happening is you have
left some low-hanging abstraction on the table.  That constrains Julia's
ability to simplify through organized multidispatch.  I will give it more than
a glance overnight -- pretend it all works perfectly, show me what you want to
do with it then.

>>>

>>>  
>>>

>>>  

>>>

>>> On Wednesday, February 17, 2016 at 3:59:15 PM UTC-5, Jake Rosoman wrote:

>>>

 Oh yup I thought that was the case but wanted to check.  
  
I've started experimenting with ways to achieve this but I am getting massive
amounts of code generated compared to Unitful. I just uploaded uploaded my
work so far at
[https://GitHub.com/jkroso/units.jl](https://GitHub.com/jkroso/units.jl). If
anyone could help explain the difference in code gen that would be great and
I'll try contribute back to Unitful  

>>>

 On Thu, 18 Feb 2016 at 7:02 AM Andrew Keller
andrew.k...@gmail.com wrote:  



> Hi Jake,

>

>  

>

> I agree with Jeffrey's response mostly, but want to clarify that Unitful
is not strictly focused on the SI system. You'll see that you can use units of
acre-feet, very much not an SI unit, which could be useful if you happen to
manage a water reservoir in the United States, I guess.

>

>  

>

> If you were instead asking whether or not you could write methods that
dispatch on the dimensions of a unit, the current answer is no, although maybe
that could change eventually.

>

>  

>

> Best,

>

> Andrew

>

>  

>

> On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff
wrote:

>

>> Jake,

>>

>>  

>>

>> Julia's type system is well suited to do just that.  Unitful is focused
on units in SI system, things like Meters, Kilograms and Joules.

>>

>>  

>>

>> One approach to abstract units like size, where size may be relative to
the number of pixels on a screen or the width of a page,

>>

>> is define your own type, a kind of size relative to something.  In your
example, s is not a unit of measure (strictly speaking);

>>

>> s is a quantity interpreted in terms of some absolute or relative unit
of measure -- 5 pixels, 1/4 page.  Because pixels and pages

>>

>> are not always the same number of, say, millimeters, using SI units for
that abstraction likely is not what you want.

>>

>>  

>>

>> If you want more guidance, please give some more context.

>>

>>  

>>

>> On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman
wrote:

>>

>>> Is it possible to talk about abstract types of units like size. e.g
`drawline(s::Size) = ...`?  
  
On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller wrote:

>>>

 I'm happy to share a package I wrote for using physical units in
Julia, [Unitful.jl](https://www.github.com/ajkeller34/Unitful.jl). Much credit
and gratitude is due to Keno Fischer for the
[SIUnits.jl](https://www.github.com/keno/SIUnits.jl) package which served as
my inspiration. This is a work in progress, but I think perhaps a serviceable
one depending on what you're doing.



  



 Like SIUnits.jl, this package encodes units in the type signature to
avoid run-time performance penalties. From there, the implementations diverge.
The package is targeted to Julia 0.5 / master, as there are some limitations
with how promote_op is used in Julia 0.4
[(#13803)](https://github.com/JuliaLang/julia/pull/13803). I decided it wasn't
worth targeting 0.4 if 

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

Yes, that can be sort of a pain. Our I/O functions all have this issue –
you have to pass the IO object through all the way down the call stack. The
alternative is to do some kind of dynamic scoping, which we don't have
language support for, so you'd have to do it manually. I.e. something like
this:

module X
export f, g
const h = Function[]
f(x) = 2g(x)
g(x) = 3h[end](x)
end

module Y
using X
function f(x)
push!(X.h, x->5x)
y = X.f(x)
pop!(X.h)
return y
end
end

julia> Y.f(7)
210



On Wed, Feb 17, 2016 at 5:40 PM, Julia Tylors  wrote:

> Thanks Stephen.
> than i will go by passing g as a parameter to f, but that will make me
> pass g down to all other functions needing g along the way in the call
> stack of f.
>
> Thanks again.
>
> On Wednesday, February 17, 2016 at 2:32:16 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> The behavior of a function does not depend on where it is called from,
>> that's a basic principle of the language and one that we are not going to
>> change. So I think the bottom line is that by design there is no way to do
>> what you're trying to do.
>>
>> On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors  wrote:
>>
>>> basically you generate the code every time  in the module of interest.
>>> but in my case, the function f is very huge and i don't want to generate it
>>> all the time.
>>> so that is not what i want to do either. I have seen that already. That
>>> is why i was asking "is there  some sort of a special AST node, which
>>> resolves the function based on the current scope the code."
>>>
>>> that would be a lot more helpful.
>>> Thanks
>>>
>>>
>>> On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
>>> wrote:

 module X
 export @make_f
 macro make_f()
 :($(esc(:f))(x) = $(esc(:g))(x))
 end
 end

 module Y
 using X
 g(x) = 3x
 @make_f
 end

 julia> Y.f(2)
 6

 On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors 
 wrote:

> Yes, exactly.
>
>
> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> So you want to have a macro that defines f for you in Y such that it
>> calls Y's g?
>>
>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
>> wrote:
>>
>>> I know, but would it be possible to generate code in module X, using
>>> g as a globally defined function so that the function g gets resolved 
>>> based
>>> on the module where f is being used?
>>>
>>> Ps: I don't want to pass g as a parameter to f.
>>>
>>> Here is an example:
>>>
>>> julia> module X
>>>   export f
>>>   g(x) = 2x
>>>   f(x) = g(x)
>>>   end
>>> X
>>>
>>> julia> module Y
>>>   using X
>>>   g(x) = 3x
>>>   println(f(4))
>>>   end
>>> 8 *# this should have been 12 if the function g is used from Y, it
>>> hasn't been used because when we look at the AST, we would see it is 
>>> making
>>> a call to the function g in module X.*
>>> Y
>>>
>>> julia> f.env.defs.func.code
>>> AST(:($(Expr(:lambda, Any[:x],
>>> Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], :(begin  # none, line 4:
>>> *return (X.g)(x) # here*
>>> end)
>>>
>>> So in the light of this, is it possible to generate code using a
>>> macro with some sort of a special AST node, which resolves the function
>>> based on the current scope the code.
>>>
>>>
>>>
>>> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan
>>> Karpinski wrote:

 There is no g defined inside of module X.

 On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
 wrote:

> julia> module X
>export f
>function f(x)
>g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) =  2x
>f(4)
>end
> ERROR: UndefVarError: g not defined
>  in f at ./none:4
>
> I am trying to use another function g(x) which can be defined in
> any other module by calling function f.
> This is the idea at its simplest. But It seems it doesn't work.
>
>
> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean
> wrote:
>>
>> Hi Julia, what are you trying to achieve, concretely?
>>
>> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors
>> wrote:
>>>
>>> I started to think, 

Re: [julia-users] Weird Hygiene Issue

[Isaiah Norton]

Taking a slightly different tack, does this example help?

julia> module X
>export f
>function g end
>f(x) = g(x)
>end
> X
>
> julia> module Y
>using X
>X.g(x) = 3x
>println(f(4))
>end
> 12
> Y


You can also add (or "inject") type-specific methods for `X.g`, as is done
in external packages for many methods in Base (Base.convert, Base.show,
etc.):
http://docs.julialang.org/en/release-0.4/manual/methods/

(you just can't avoid the time required to Just-in-Time compile new
specializations based on the new methods -- but that is true of all method
definitions)

On Wed, Feb 17, 2016 at 5:40 PM, Julia Tylors  wrote:

> Thanks Stephen.
> than i will go by passing g as a parameter to f, but that will make me
> pass g down to all other functions needing g along the way in the call
> stack of f.
>
> Thanks again.
>
> On Wednesday, February 17, 2016 at 2:32:16 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> The behavior of a function does not depend on where it is called from,
>> that's a basic principle of the language and one that we are not going to
>> change. So I think the bottom line is that by design there is no way to do
>> what you're trying to do.
>>
>> On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors  wrote:
>>
>>> basically you generate the code every time  in the module of interest.
>>> but in my case, the function f is very huge and i don't want to generate it
>>> all the time.
>>> so that is not what i want to do either. I have seen that already. That
>>> is why i was asking "is there  some sort of a special AST node, which
>>> resolves the function based on the current scope the code."
>>>
>>> that would be a lot more helpful.
>>> Thanks
>>>
>>>
>>> On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
>>> wrote:

 module X
 export @make_f
 macro make_f()
 :($(esc(:f))(x) = $(esc(:g))(x))
 end
 end

 module Y
 using X
 g(x) = 3x
 @make_f
 end

 julia> Y.f(2)
 6

 On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors 
 wrote:

> Yes, exactly.
>
>
> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> So you want to have a macro that defines f for you in Y such that it
>> calls Y's g?
>>
>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
>> wrote:
>>
>>> I know, but would it be possible to generate code in module X, using
>>> g as a globally defined function so that the function g gets resolved 
>>> based
>>> on the module where f is being used?
>>>
>>> Ps: I don't want to pass g as a parameter to f.
>>>
>>> Here is an example:
>>>
>>> julia> module X
>>>   export f
>>>   g(x) = 2x
>>>   f(x) = g(x)
>>>   end
>>> X
>>>
>>> julia> module Y
>>>   using X
>>>   g(x) = 3x
>>>   println(f(4))
>>>   end
>>> 8 *# this should have been 12 if the function g is used from Y, it
>>> hasn't been used because when we look at the AST, we would see it is 
>>> making
>>> a call to the function g in module X.*
>>> Y
>>>
>>> julia> f.env.defs.func.code
>>> AST(:($(Expr(:lambda, Any[:x],
>>> Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], :(begin  # none, line 4:
>>> *return (X.g)(x) # here*
>>> end)
>>>
>>> So in the light of this, is it possible to generate code using a
>>> macro with some sort of a special AST node, which resolves the function
>>> based on the current scope the code.
>>>
>>>
>>>
>>> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan
>>> Karpinski wrote:

 There is no g defined inside of module X.

 On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
 wrote:

> julia> module X
>export f
>function f(x)
>g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) =  2x
>f(4)
>end
> ERROR: UndefVarError: g not defined
>  in f at ./none:4
>
> I am trying to use another function g(x) which can be defined in
> any other module by calling function f.
> This is the idea at its simplest. But It seems it doesn't work.
>
>
> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean
> wrote:
>>
>> Hi Julia, what are you trying to achieve, concretely?
>>
>> On Monday, February 15, 2016 at 2:36:15 PM 

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

Thanks Stephen.
than i will go by passing g as a parameter to f, but that will make me pass 
g down to all other functions needing g along the way in the call stack of 
f.

Thanks again.

On Wednesday, February 17, 2016 at 2:32:16 PM UTC-8, Stefan Karpinski wrote:
>
> The behavior of a function does not depend on where it is called from, 
> that's a basic principle of the language and one that we are not going to 
> change. So I think the bottom line is that by design there is no way to do 
> what you're trying to do.
>
> On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors  > wrote:
>
>> basically you generate the code every time  in the module of interest. 
>> but in my case, the function f is very huge and i don't want to generate it 
>> all the time. 
>> so that is not what i want to do either. I have seen that already. That 
>> is why i was asking "is there  some sort of a special AST node, which 
>> resolves the function based on the current scope the code."
>>
>> that would be a lot more helpful.
>> Thanks 
>>
>>
>> On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski 
>> wrote:
>>>
>>> module X
>>> export @make_f
>>> macro make_f()
>>> :($(esc(:f))(x) = $(esc(:g))(x))
>>> end
>>> end
>>>
>>> module Y
>>> using X
>>> g(x) = 3x
>>> @make_f
>>> end
>>>
>>> julia> Y.f(2)
>>> 6
>>>
>>> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors  
>>> wrote:
>>>
 Yes, exactly.


 On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski 
 wrote:
>
> So you want to have a macro that defines f for you in Y such that it 
> calls Y's g?
>
> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors  
> wrote:
>
>> I know, but would it be possible to generate code in module X, using 
>> g as a globally defined function so that the function g gets resolved 
>> based 
>> on the module where f is being used?
>>
>> Ps: I don't want to pass g as a parameter to f. 
>>
>> Here is an example:
>>
>> julia> module X
>>   export f
>>   g(x) = 2x
>>   f(x) = g(x)
>>   end
>> X
>>
>> julia> module Y
>>   using X
>>   g(x) = 3x
>>   println(f(4))
>>   end
>> 8 *# this should have been 12 if the function g is used from Y, it 
>> hasn't been used because when we look at the AST, we would see it is 
>> making 
>> a call to the function g in module X.*
>> Y
>>
>> julia> f.env.defs.func.code
>> AST(:($(Expr(:lambda, Any[:x], 
>> Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], :(begin  # none, line 4:
>> *return (X.g)(x) # here*
>> end)
>>
>> So in the light of this, is it possible to generate code using a 
>> macro with some sort of a special AST node, which resolves the function 
>> based on the current scope the code.
>>
>>
>>
>> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski 
>> wrote:
>>>
>>> There is no g defined inside of module X.
>>>
>>> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  
>>> wrote:
>>>
 julia> module X
export f
function f(x)
g(x)
end
end
 X

 julia> module Y
using X
g(x) =  2x
f(4)
end
 ERROR: UndefVarError: g not defined
  in f at ./none:4

 I am trying to use another function g(x) which can be defined in 
 any other module by calling function f.
 This is the idea at its simplest. But It seems it doesn't work.


 On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean 
 wrote:
>
> Hi Julia, what are you trying to achieve, concretely? 
>
> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors 
> wrote:
>>
>> I started to think, this may be normal working of julia.
>>
>> import X:_ex_func
>> using X
>> _ex_func() = println("DDD")
>> _1ex_func()
>> julia> _1ex_func()
>> DDD
>> sty
>>
>> julia> module Y
>>   using X
>>   _
>> _1ex_func  __precompile__  _ex_func
>> julia> module Y
>>   using X
>>   _1ex_func()
>>   end
>> DDD
>> sty
>> Y
>>
>> However, it seems once a function is overridden, it stays 
>> overridden in every module.
>> That is a very weird idea. why is there such a design decision? 
>> Can someone care to 

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

True, although that redefines X.g, which will affect all callers of f, not
just Y.

On Wed, Feb 17, 2016 at 5:36 PM, Bart Janssens  wrote:

> Hi Julia,
>
> Not sure if this helps, but wrapping the g definition in X.eval like this:
>
> module Y
> using X
> X.eval(:(g(x) = 2x))
> f(4)
> end
>
> seems to make your sample work.
>
> On Wednesday, February 17, 2016 at 9:19:55 PM UTC+1, Julia Tylors wrote:
>>
>> julia> module X
>>export f
>>function f(x)
>>g(x)
>>end
>>end
>> X
>>
>> julia> module Y
>>using X
>>g(x) =  2x
>>f(4)
>>end
>> ERROR: UndefVarError: g not defined
>>  in f at ./none:4
>>
>>

Re: [julia-users] Weird Hygiene Issue

[Bart Janssens]

Hi Julia,

Not sure if this helps, but wrapping the g definition in X.eval like this:

module Y
using X
X.eval(:(g(x) = 2x))
f(4)
end

seems to make your sample work.

On Wednesday, February 17, 2016 at 9:19:55 PM UTC+1, Julia Tylors wrote:
>
> julia> module X
>export f
>function f(x)
>g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) =  2x
>f(4)
>end
> ERROR: UndefVarError: g not defined
>  in f at ./none:4
>
>

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

The behavior of a function does not depend on where it is called from,
that's a basic principle of the language and one that we are not going to
change. So I think the bottom line is that by design there is no way to do
what you're trying to do.

On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors  wrote:

> basically you generate the code every time  in the module of interest. but
> in my case, the function f is very huge and i don't want to generate it all
> the time.
> so that is not what i want to do either. I have seen that already. That is
> why i was asking "is there  some sort of a special AST node, which resolves
> the function based on the current scope the code."
>
> that would be a lot more helpful.
> Thanks
>
>
> On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> module X
>> export @make_f
>> macro make_f()
>> :($(esc(:f))(x) = $(esc(:g))(x))
>> end
>> end
>>
>> module Y
>> using X
>> g(x) = 3x
>> @make_f
>> end
>>
>> julia> Y.f(2)
>> 6
>>
>> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors  wrote:
>>
>>> Yes, exactly.
>>>
>>>
>>> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
>>> wrote:

 So you want to have a macro that defines f for you in Y such that it
 calls Y's g?

 On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
 wrote:

> I know, but would it be possible to generate code in module X, using g
> as a globally defined function so that the function g gets resolved based
> on the module where f is being used?
>
> Ps: I don't want to pass g as a parameter to f.
>
> Here is an example:
>
> julia> module X
>   export f
>   g(x) = 2x
>   f(x) = g(x)
>   end
> X
>
> julia> module Y
>   using X
>   g(x) = 3x
>   println(f(4))
>   end
> 8 *# this should have been 12 if the function g is used from Y, it
> hasn't been used because when we look at the AST, we would see it is 
> making
> a call to the function g in module X.*
> Y
>
> julia> f.env.defs.func.code
> AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]],
> :(begin  # none, line 4:
> *return (X.g)(x) # here*
> end)
>
> So in the light of this, is it possible to generate code using a macro
> with some sort of a special AST node, which resolves the function based on
> the current scope the code.
>
>
>
> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> There is no g defined inside of module X.
>>
>> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
>> wrote:
>>
>>> julia> module X
>>>export f
>>>function f(x)
>>>g(x)
>>>end
>>>end
>>> X
>>>
>>> julia> module Y
>>>using X
>>>g(x) =  2x
>>>f(4)
>>>end
>>> ERROR: UndefVarError: g not defined
>>>  in f at ./none:4
>>>
>>> I am trying to use another function g(x) which can be defined in any
>>> other module by calling function f.
>>> This is the idea at its simplest. But It seems it doesn't work.
>>>
>>>
>>> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean
>>> wrote:

 Hi Julia, what are you trying to achieve, concretely?

 On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors
 wrote:
>
> I started to think, this may be normal working of julia.
>
> import X:_ex_func
> using X
> _ex_func() = println("DDD")
> _1ex_func()
> julia> _1ex_func()
> DDD
> sty
>
> julia> module Y
>   using X
>   _
> _1ex_func  __precompile__  _ex_func
> julia> module Y
>   using X
>   _1ex_func()
>   end
> DDD
> sty
> Y
>
> However, it seems once a function is overridden, it stays
> overridden in every module.
> That is a very weird idea. why is there such a design decision?
> Can someone care to explain it?
>
> Thanks
>
> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors
> wrote:
>>
>> Guys, this is no solution to my problem,
>>
>> escaping basically tells the the quoted expr to be resolved
>> outside the macro as Lutfullah did. However in my case, escaping a 
>> function
>> call doesn't work for some reason.
>> And for that matter, esc 

Re: [julia-users] Re: Unitful.jl for physical units

[Jeffrey Sarnoff]

In this unit-land, is length always quantity * unit_of_length? or also may 
it be proportion * reference_distance (1/4 of the current line length)?
Or -- shall we seek an avenue that somehow is both without being either?

On Wednesday, February 17, 2016 at 5:10:15 PM UTC-5, Jake Rosoman wrote:
>
> Oops thanks for being patient. By "this" I meant "dispatch on abstract 
> units/dimensions". The motivation is to be able to write a function which 
> takes a length without caring what the specific unit of that length is. Be 
> it feet or cm etc. This is to make the intent of the function clearer and 
> enable polymorphism. For example:
>
> direction = 0radians
> move(r::Angle) = direction += r
> move(l::Length) = translate(direction, l)
>
> Also speed could be defined as Ratio{d<:size, t<:time}. Which would be 
> hard to do using unitful as is
> On Thu, 18 Feb 2016 at 10:25 AM Jeffrey Sarnoff  > wrote:
>
>> Jake,
>>
>> It would be helpful to know more clearly what is the "this" that you are 
>> experimenting with "ways to achieve this"?  
>> I took a glance at your code, and one thing that is happening is you have 
>> left some low-hanging abstraction on the table.  That constrains Julia's 
>> ability to simplify through organized multidispatch.  I will give it more 
>> than a glance overnight -- pretend it all works perfectly, show me what you 
>> want to do with it then.
>>
>>
>> On Wednesday, February 17, 2016 at 3:59:15 PM UTC-5, Jake Rosoman wrote:
>>
>>> Oh yup I thought that was the case but wanted to check. 
>>>
>>> I've started experimenting with ways to achieve this but I am getting 
>>> massive amounts of code generated compared to Unitful. I just uploaded 
>>> uploaded my work so far at https://GitHub.com/jkroso/units.jl. If 
>>> anyone could help explain the difference in code gen that would be great 
>>> and I'll try contribute back to Unitful
>>>
>> On Thu, 18 Feb 2016 at 7:02 AM Andrew Keller  
>>> wrote:
>>>
 Hi Jake,

 I agree with Jeffrey's response mostly, but want to clarify that 
 Unitful is not strictly focused on the SI system. You'll see that you can 
 use units of acre-feet, very much not an SI unit, which could be useful if 
 you happen to manage a water reservoir in the United States, I guess.

 If you were instead asking whether or not you could write methods that 
 dispatch on the dimensions of a unit, the current answer is no, although 
 maybe that could change eventually.

 Best,
 Andrew

 On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff 
 wrote:
>
> Jake,
>
> Julia's type system is well suited to do just that.  Unitful is 
> focused on units in SI system, things like Meters, Kilograms and Joules.
>
> One approach to abstract units like size, where size may be relative 
> to the number of pixels on a screen or the width of a page,
> is define your own type, a kind of size relative to something.  In 
> your example, s is not a unit of measure (strictly speaking);
> s is a quantity interpreted in terms of some absolute or relative unit 
> of measure -- 5 pixels, 1/4 page.  Because pixels and pages
> are not always the same number of, say, millimeters, using SI units 
> for that abstraction likely is not what you want.
>
> If you want more guidance, please give some more context.
>
> On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman 
> wrote:
>>
>> Is it possible to talk about abstract types of units like size. e.g 
>> `drawline(s::Size) = ...`?
>>
>> On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller 
>> wrote:
>>>
>>> I'm happy to share a package I wrote for using physical units in 
>>> Julia, Unitful.jl . 
>>> Much credit and gratitude is due to Keno Fischer for the SIUnits.jl 
>>>  package which served as my 
>>> inspiration. This is a work in progress, but I think perhaps a 
>>> serviceable 
>>> one depending on what you're doing. 
>>>
>>> Like SIUnits.jl, this package encodes units in the type signature to 
>>> avoid run-time performance penalties. From there, the 
>>> implementations diverge. The package is targeted to Julia 0.5 / master, 
>>> as 
>>> there are some limitations with how promote_op is used in Julia 0.4 
>>> (#13803) . I decided 
>>> it wasn't worth targeting 0.4 if the behavior would be inconsistent. 
>>>
>>> Some highlights include:
>>>
>>>- Non-SI units are treated on the same footing as SI units, with 
>>>only a few exceptions (unit conversion method). Use whatever 
>>>weird units you want.
>>>- Support for units like micron / (meter Kelvin), where some of 

Re: [julia-users] Weird Hygiene Issue

[Cedric St-Jean]

>
> but in my case, the function f is very huge and i don't want to generate
> it all the time.
>

Why do you want to have the same function generated in every module?

On Wed, Feb 17, 2016 at 5:20 PM, Julia Tylors  wrote:

> basically you generate the code every time  in the module of interest. but
> in my case, the function f is very huge and i don't want to generate it all
> the time.
> so that is not what i want to do either. I have seen that already. That is
> why i was asking "is there  some sort of a special AST node, which resolves
> the function based on the current scope the code."
>
> that would be a lot more helpful.
> Thanks
>
>
> On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> module X
>> export @make_f
>> macro make_f()
>> :($(esc(:f))(x) = $(esc(:g))(x))
>> end
>> end
>>
>> module Y
>> using X
>> g(x) = 3x
>> @make_f
>> end
>>
>> julia> Y.f(2)
>> 6
>>
>> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors  wrote:
>>
>>> Yes, exactly.
>>>
>>>
>>> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
>>> wrote:

 So you want to have a macro that defines f for you in Y such that it
 calls Y's g?

 On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors 
 wrote:

> I know, but would it be possible to generate code in module X, using g
> as a globally defined function so that the function g gets resolved based
> on the module where f is being used?
>
> Ps: I don't want to pass g as a parameter to f.
>
> Here is an example:
>
> julia> module X
>   export f
>   g(x) = 2x
>   f(x) = g(x)
>   end
> X
>
> julia> module Y
>   using X
>   g(x) = 3x
>   println(f(4))
>   end
> 8 *# this should have been 12 if the function g is used from Y, it
> hasn't been used because when we look at the AST, we would see it is 
> making
> a call to the function g in module X.*
> Y
>
> julia> f.env.defs.func.code
> AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]],
> :(begin  # none, line 4:
> *return (X.g)(x) # here*
> end)
>
> So in the light of this, is it possible to generate code using a macro
> with some sort of a special AST node, which resolves the function based on
> the current scope the code.
>
>
>
> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> There is no g defined inside of module X.
>>
>> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
>> wrote:
>>
>>> julia> module X
>>>export f
>>>function f(x)
>>>g(x)
>>>end
>>>end
>>> X
>>>
>>> julia> module Y
>>>using X
>>>g(x) =  2x
>>>f(4)
>>>end
>>> ERROR: UndefVarError: g not defined
>>>  in f at ./none:4
>>>
>>> I am trying to use another function g(x) which can be defined in any
>>> other module by calling function f.
>>> This is the idea at its simplest. But It seems it doesn't work.
>>>
>>>
>>> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean
>>> wrote:

 Hi Julia, what are you trying to achieve, concretely?

 On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors
 wrote:
>
> I started to think, this may be normal working of julia.
>
> import X:_ex_func
> using X
> _ex_func() = println("DDD")
> _1ex_func()
> julia> _1ex_func()
> DDD
> sty
>
> julia> module Y
>   using X
>   _
> _1ex_func  __precompile__  _ex_func
> julia> module Y
>   using X
>   _1ex_func()
>   end
> DDD
> sty
> Y
>
> However, it seems once a function is overridden, it stays
> overridden in every module.
> That is a very weird idea. why is there such a design decision?
> Can someone care to explain it?
>
> Thanks
>
> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors
> wrote:
>>
>> Guys, this is no solution to my problem,
>>
>> escaping basically tells the the quoted expr to be resolved
>> outside the macro as Lutfullah did. However in my case, escaping a 
>> function
>> call doesn't work for some reason.
>> And for that matter, esc should be recursive though...
>>
>>
>> On Monday, February 

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

basically you generate the code every time  in the module of interest. but 
in my case, the function f is very huge and i don't want to generate it all 
the time. 
so that is not what i want to do either. I have seen that already. That is 
why i was asking "is there  some sort of a special AST node, which resolves 
the function based on the current scope the code."

that would be a lot more helpful.
Thanks 


On Wednesday, February 17, 2016 at 2:12:31 PM UTC-8, Stefan Karpinski wrote:
>
> module X
> export @make_f
> macro make_f()
> :($(esc(:f))(x) = $(esc(:g))(x))
> end
> end
>
> module Y
> using X
> g(x) = 3x
> @make_f
> end
>
> julia> Y.f(2)
> 6
>
> On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors  > wrote:
>
>> Yes, exactly.
>>
>>
>> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski 
>> wrote:
>>>
>>> So you want to have a macro that defines f for you in Y such that it 
>>> calls Y's g?
>>>
>>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors  
>>> wrote:
>>>
 I know, but would it be possible to generate code in module X, using g 
 as a globally defined function so that the function g gets resolved based 
 on the module where f is being used?

 Ps: I don't want to pass g as a parameter to f. 

 Here is an example:

 julia> module X
   export f
   g(x) = 2x
   f(x) = g(x)
   end
 X

 julia> module Y
   using X
   g(x) = 3x
   println(f(4))
   end
 8 *# this should have been 12 if the function g is used from Y, it 
 hasn't been used because when we look at the AST, we would see it is 
 making 
 a call to the function g in module X.*
 Y

 julia> f.env.defs.func.code
 AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], 
 :(begin  # none, line 4:
 *return (X.g)(x) # here*
 end)

 So in the light of this, is it possible to generate code using a macro 
 with some sort of a special AST node, which resolves the function based on 
 the current scope the code.



 On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski 
 wrote:
>
> There is no g defined inside of module X.
>
> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  
> wrote:
>
>> julia> module X
>>export f
>>function f(x)
>>g(x)
>>end
>>end
>> X
>>
>> julia> module Y
>>using X
>>g(x) =  2x
>>f(4)
>>end
>> ERROR: UndefVarError: g not defined
>>  in f at ./none:4
>>
>> I am trying to use another function g(x) which can be defined in any 
>> other module by calling function f.
>> This is the idea at its simplest. But It seems it doesn't work.
>>
>>
>> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean 
>> wrote:
>>>
>>> Hi Julia, what are you trying to achieve, concretely? 
>>>
>>> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:

 I started to think, this may be normal working of julia.

 import X:_ex_func
 using X
 _ex_func() = println("DDD")
 _1ex_func()
 julia> _1ex_func()
 DDD
 sty

 julia> module Y
   using X
   _
 _1ex_func  __precompile__  _ex_func
 julia> module Y
   using X
   _1ex_func()
   end
 DDD
 sty
 Y

 However, it seems once a function is overridden, it stays 
 overridden in every module.
 That is a very weird idea. why is there such a design decision? Can 
 someone care to explain it?

 Thanks

 On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors 
 wrote:
>
> Guys, this is no solution to my problem, 
>
> escaping basically tells the the quoted expr to be resolved 
> outside the macro as Lutfullah did. However in my case, escaping a 
> function 
> call doesn't work for some reason.
> And for that matter, esc should be recursive though...
>
>
> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco 
> wrote:
>>
>> On February 14, 2016 at 21:49:30, Julia Tylors (
>> julia...@gmail.com(mailto:juliatyl...@gmail.com)) wrote: 
>>
>> > Hi fellows,   
>> >   
>> >   
>> > I was coding a macro, and I am having a prefix issue with 
>> functions.   
>> >   

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

module X
export @make_f
macro make_f()
:($(esc(:f))(x) = $(esc(:g))(x))
end
end

module Y
using X
g(x) = 3x
@make_f
end

julia> Y.f(2)
6

On Wed, Feb 17, 2016 at 5:01 PM, Julia Tylors  wrote:

> Yes, exactly.
>
>
> On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> So you want to have a macro that defines f for you in Y such that it
>> calls Y's g?
>>
>> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors  wrote:
>>
>>> I know, but would it be possible to generate code in module X, using g
>>> as a globally defined function so that the function g gets resolved based
>>> on the module where f is being used?
>>>
>>> Ps: I don't want to pass g as a parameter to f.
>>>
>>> Here is an example:
>>>
>>> julia> module X
>>>   export f
>>>   g(x) = 2x
>>>   f(x) = g(x)
>>>   end
>>> X
>>>
>>> julia> module Y
>>>   using X
>>>   g(x) = 3x
>>>   println(f(4))
>>>   end
>>> 8 *# this should have been 12 if the function g is used from Y, it
>>> hasn't been used because when we look at the AST, we would see it is making
>>> a call to the function g in module X.*
>>> Y
>>>
>>> julia> f.env.defs.func.code
>>> AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]],
>>> :(begin  # none, line 4:
>>> *return (X.g)(x) # here*
>>> end)
>>>
>>> So in the light of this, is it possible to generate code using a macro
>>> with some sort of a special AST node, which resolves the function based on
>>> the current scope the code.
>>>
>>>
>>>
>>> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski
>>> wrote:

 There is no g defined inside of module X.

 On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors 
 wrote:

> julia> module X
>export f
>function f(x)
>g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) =  2x
>f(4)
>end
> ERROR: UndefVarError: g not defined
>  in f at ./none:4
>
> I am trying to use another function g(x) which can be defined in any
> other module by calling function f.
> This is the idea at its simplest. But It seems it doesn't work.
>
>
> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:
>>
>> Hi Julia, what are you trying to achieve, concretely?
>>
>> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>>>
>>> I started to think, this may be normal working of julia.
>>>
>>> import X:_ex_func
>>> using X
>>> _ex_func() = println("DDD")
>>> _1ex_func()
>>> julia> _1ex_func()
>>> DDD
>>> sty
>>>
>>> julia> module Y
>>>   using X
>>>   _
>>> _1ex_func  __precompile__  _ex_func
>>> julia> module Y
>>>   using X
>>>   _1ex_func()
>>>   end
>>> DDD
>>> sty
>>> Y
>>>
>>> However, it seems once a function is overridden, it stays overridden
>>> in every module.
>>> That is a very weird idea. why is there such a design decision? Can
>>> someone care to explain it?
>>>
>>> Thanks
>>>
>>> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors
>>> wrote:

 Guys, this is no solution to my problem,

 escaping basically tells the the quoted expr to be resolved outside
 the macro as Lutfullah did. However in my case, escaping a function 
 call
 doesn't work for some reason.
 And for that matter, esc should be recursive though...


 On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco
 wrote:
>
> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
> (mailto:juliatyl...@gmail.com)) wrote:
>
> > Hi fellows,
> >
> >
> > I was coding a macro, and I am having a prefix issue with
> functions.
> >
> > basically the problem is: Every single one of available
> functions (_ex_func) which i want to be globally accessible are 
> prefixed
> with the name of the module(X) in which the macro f is defined
> >
> >
> > Here is the code example:
> >
> > julia> module X
> > export @f
> > macro f(x)
> > st = string("_",x)
> > sy = symbol(st)
> > esc(quote
> > function ($sy)()
> > println("st")
> > end
> >
> > function ($(symbol(string("_1",x()
> > ($sy)()
> > println("sty")
> > end
> > export $sy
> > export $(symbol(string("_1",x)))

Re: [julia-users] Re: Unitful.jl for physical units

[Jake Rosoman]

Oops thanks for being patient. By "this" I meant "dispatch on abstract
units/dimensions". The motivation is to be able to write a function which
takes a length without caring what the specific unit of that length is. Be
it feet or cm etc. This is to make the intent of the function clearer and
enable polymorphism. For example:

direction = 0radians
move(r::Angle) = direction += r
move(l::Length) = translate(direction, l)

Also speed could be defined as Ratio{d<:size, t<:time}. Which would be hard
to do using unitful as is
On Thu, 18 Feb 2016 at 10:25 AM Jeffrey Sarnoff 
wrote:

> Jake,
>
> It would be helpful to know more clearly what is the "this" that you are
> experimenting with "ways to achieve this"?
> I took a glance at your code, and one thing that is happening is you have
> left some low-hanging abstraction on the table.  That constrains Julia's
> ability to simplify through organized multidispatch.  I will give it more
> than a glance overnight -- pretend it all works perfectly, show me what you
> want to do with it then.
>
>
> On Wednesday, February 17, 2016 at 3:59:15 PM UTC-5, Jake Rosoman wrote:
>
>> Oh yup I thought that was the case but wanted to check.
>>
>> I've started experimenting with ways to achieve this but I am getting
>> massive amounts of code generated compared to Unitful. I just uploaded
>> uploaded my work so far at https://GitHub.com/jkroso/units.jl. If anyone
>> could help explain the difference in code gen that would be great and I'll
>> try contribute back to Unitful
>>
> On Thu, 18 Feb 2016 at 7:02 AM Andrew Keller 
>> wrote:
>>
>>> Hi Jake,
>>>
>>> I agree with Jeffrey's response mostly, but want to clarify that Unitful
>>> is not strictly focused on the SI system. You'll see that you can use units
>>> of acre-feet, very much not an SI unit, which could be useful if you happen
>>> to manage a water reservoir in the United States, I guess.
>>>
>>> If you were instead asking whether or not you could write methods that
>>> dispatch on the dimensions of a unit, the current answer is no, although
>>> maybe that could change eventually.
>>>
>>> Best,
>>> Andrew
>>>
>>> On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff
>>> wrote:

 Jake,

 Julia's type system is well suited to do just that.  Unitful is focused
 on units in SI system, things like Meters, Kilograms and Joules.

 One approach to abstract units like size, where size may be relative to
 the number of pixels on a screen or the width of a page,
 is define your own type, a kind of size relative to something.  In your
 example, s is not a unit of measure (strictly speaking);
 s is a quantity interpreted in terms of some absolute or relative unit
 of measure -- 5 pixels, 1/4 page.  Because pixels and pages
 are not always the same number of, say, millimeters, using SI units for
 that abstraction likely is not what you want.

 If you want more guidance, please give some more context.

 On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman wrote:
>
> Is it possible to talk about abstract types of units like size. e.g
> `drawline(s::Size) = ...`?
>
> On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller
> wrote:
>>
>> I'm happy to share a package I wrote for using physical units in
>> Julia, Unitful.jl .
>> Much credit and gratitude is due to Keno Fischer for the SIUnits.jl
>>  package which served as my
>> inspiration. This is a work in progress, but I think perhaps a 
>> serviceable
>> one depending on what you're doing.
>>
>> Like SIUnits.jl, this package encodes units in the type signature to
>> avoid run-time performance penalties. From there, the
>> implementations diverge. The package is targeted to Julia 0.5 / master, 
>> as
>> there are some limitations with how promote_op is used in Julia 0.4
>> (#13803) . I decided
>> it wasn't worth targeting 0.4 if the behavior would be inconsistent.
>>
>> Some highlights include:
>>
>>- Non-SI units are treated on the same footing as SI units, with
>>only a few exceptions (unit conversion method). Use whatever
>>weird units you want.
>>- Support for units like micron / (meter Kelvin), where some of
>>the units could cancel out but you don't necessarily want them to.
>>- Support for LinSpace and other Range types. Probably there are
>>still some glitches to be found, though.
>>- Support for rational exponents of units.
>>- Some tests (see these for usage examples).
>>
>> Please see the documentation for a comprehensive discussion,
>> including issues / to do list, as well as how to add your own units, 

[julia-users] Re: Weird Hygiene Issue

[Simon Danisch]

Why not:

module X
  export f
  g(x) = 2x
  f(x, g=g) = g(x)
end

module Y
  using X
  g(x) = 3x
  println(f(4, g))
end

?

Am Sonntag, 14. Februar 2016 20:49:24 UTC+1 schrieb Julia Tylors:
>
> Hi fellows,
>
>
> I was coding a macro, and I am having a prefix issue with functions.
>
> basically the problem is: Every single one of  available functions 
> (_ex_func) which i want to be globally accessible are prefixed with the 
> name of the module(X)  in which the macro f is defined
>
>
> Here is the code example:
>
> julia> module X
> export @f
> macro f(x)
> st = string("_",x)
> sy = symbol(st)
> esc(quote
> function ($sy)()
> println("st")
> end
>
> function ($(symbol(string("_1",x()
> ($sy)()
> println("sty")
> end
> export $sy
> export $(symbol(string("_1",x)))
> end
> )
> end
> @eval @f ex_func
>end
> X
>
> julia> using X
>
> julia> _
>
> _1ex_func  __precompile__  _ex_func
> julia> _1ex_func.env.defs.func.code
> AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin  # none, 
> line 12:
> *(X._ex_func)() # none, line 13: # i want this to be not prefixed 
> by X*
> return (X.println)("sty")
> end)
>
> julia> macroexpand(:(@f ex_func))
> quote  # none, line 7:
> function _ex_func() # none, line 8:
> println("st")
> end # none, line 11:
> function _1ex_func() # none, line 12:
> *_ex_func() # none, line 13: # it seems OK, here!!!*
> println("sty")
> end # none, line 15:
> export _ex_func # none, line 16:
> export _1ex_func
> end
>
> as you may see , I may well define _ex_func in other modules and use it 
> from the function X._1ex_func().
> But this prevents me doing it.
>
> How can i solve this problem?
>
> Thanks
>

Re: [julia-users] Re: Blog-post on how to make package documentation

[Mauro]

Actually, Mike, is there a way to sort the API docs? Alphabetical or to
some given order?

On Wed, 2016-02-17 at 17:44, Michael Hatherly  wrote:
> Thanks for writing that up Mauro and also the shout-out :) Worth noting
> Mike Innes' important work in getting the docsystem integrated into `Base`
> and his
> heroic effort converting most of the docs from rst to markdown as well.
>
> On a technical note, Lexicon doesn't actually use the docsystem in `Base`
> at all and still relies on Docile's own implementation currently, so it's
> possible
> that people may start to run into problems with this approach on 0.5 as it
> further diverges from 0.3/0.4. (Do open issues if they happen to crop up
> though and I'll do my best to keep things working as long as possible.)
> Future work using the `Base` docsystem for documentation generation is
> moving
> ahead, when time allows, in a separate
> package, https://github.com/MichaelHatherly/Lapidary.jl.
>
> -- Mike
>
> On Wednesday, 17 February 2016 17:13:38 UTC+2, Mauro wrote:
>>
>> Until a few days ago, I was a bit confused on how to go about writing
>> nice package documentation, including API-docs.  I figured it out and it
>> turned out to be pretty trivial, once I knew how.  I wrote it up in case
>> someone else is confused (or I become confused again):
>> http://maurow.bitbucket.org/notes/documenting-a-julia-package.html
>> (feedback welcome)
>>
>>   Mauro
>>

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

Yes, exactly.


On Wednesday, February 17, 2016 at 1:53:57 PM UTC-8, Stefan Karpinski wrote:
>
> So you want to have a macro that defines f for you in Y such that it calls 
> Y's g?
>
> On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors  > wrote:
>
>> I know, but would it be possible to generate code in module X, using g as 
>> a globally defined function so that the function g gets resolved based on 
>> the module where f is being used?
>>
>> Ps: I don't want to pass g as a parameter to f. 
>>
>> Here is an example:
>>
>> julia> module X
>>   export f
>>   g(x) = 2x
>>   f(x) = g(x)
>>   end
>> X
>>
>> julia> module Y
>>   using X
>>   g(x) = 3x
>>   println(f(4))
>>   end
>> 8 *# this should have been 12 if the function g is used from Y, it 
>> hasn't been used because when we look at the AST, we would see it is making 
>> a call to the function g in module X.*
>> Y
>>
>> julia> f.env.defs.func.code
>> AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], 
>> :(begin  # none, line 4:
>> *return (X.g)(x) # here*
>> end)
>>
>> So in the light of this, is it possible to generate code using a macro 
>> with some sort of a special AST node, which resolves the function based on 
>> the current scope the code.
>>
>>
>>
>> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski 
>> wrote:
>>>
>>> There is no g defined inside of module X.
>>>
>>> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  
>>> wrote:
>>>
 julia> module X
export f
function f(x)
g(x)
end
end
 X

 julia> module Y
using X
g(x) =  2x
f(4)
end
 ERROR: UndefVarError: g not defined
  in f at ./none:4

 I am trying to use another function g(x) which can be defined in any 
 other module by calling function f.
 This is the idea at its simplest. But It seems it doesn't work.


 On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:
>
> Hi Julia, what are you trying to achieve, concretely? 
>
> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>>
>> I started to think, this may be normal working of julia.
>>
>> import X:_ex_func
>> using X
>> _ex_func() = println("DDD")
>> _1ex_func()
>> julia> _1ex_func()
>> DDD
>> sty
>>
>> julia> module Y
>>   using X
>>   _
>> _1ex_func  __precompile__  _ex_func
>> julia> module Y
>>   using X
>>   _1ex_func()
>>   end
>> DDD
>> sty
>> Y
>>
>> However, it seems once a function is overridden, it stays overridden 
>> in every module.
>> That is a very weird idea. why is there such a design decision? Can 
>> someone care to explain it?
>>
>> Thanks
>>
>> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>>>
>>> Guys, this is no solution to my problem, 
>>>
>>> escaping basically tells the the quoted expr to be resolved outside 
>>> the macro as Lutfullah did. However in my case, escaping a function 
>>> call 
>>> doesn't work for some reason.
>>> And for that matter, esc should be recursive though...
>>>
>>>
>>> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco 
>>> wrote:

 On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
 (mailto:juliatyl...@gmail.com)) wrote: 

 > Hi fellows,   
 >   
 >   
 > I was coding a macro, and I am having a prefix issue with 
 functions.   
 >   
 > basically the problem is: Every single one of available functions 
 (_ex_func) which i want to be globally accessible are prefixed with 
 the 
 name of the module(X) in which the macro f is defined   
 >   
 >   
 > Here is the code example:   
 >   
 > julia> module X   
 > export @f 
 > macro f(x) 
 > st = string("_",x) 
 > sy = symbol(st) 
 > esc(quote 
 > function ($sy)() 
 > println("st") 
 > end 
 >   
 > function ($(symbol(string("_1",x()   
 > ($sy)() 
 > println("sty") 
 > end 
 > export $sy 
 > export $(symbol(string("_1",x))) 
 > end 
 > ) 
 > end 
 > @eval @f ex_func 
 > end 
 > X 
 >   
 > julia> using X   
 >   
 > julia> _   
 >   
 > _1ex_func __precompile__ _ex_func   
 > julia> _1ex_func.env.defs.func.code 
 > AST(:($(Expr(:lambda, Any[], 

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

So you want to have a macro that defines f for you in Y such that it calls
Y's g?

On Wed, Feb 17, 2016 at 4:48 PM, Julia Tylors  wrote:

> I know, but would it be possible to generate code in module X, using g as
> a globally defined function so that the function g gets resolved based on
> the module where f is being used?
>
> Ps: I don't want to pass g as a parameter to f.
>
> Here is an example:
>
> julia> module X
>   export f
>   g(x) = 2x
>   f(x) = g(x)
>   end
> X
>
> julia> module Y
>   using X
>   g(x) = 3x
>   println(f(4))
>   end
> 8 *# this should have been 12 if the function g is used from Y, it hasn't
> been used because when we look at the AST, we would see it is making a call
> to the function g in module X.*
> Y
>
> julia> f.env.defs.func.code
> AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]],
> :(begin  # none, line 4:
> *return (X.g)(x) # here*
> end)
>
> So in the light of this, is it possible to generate code using a macro
> with some sort of a special AST node, which resolves the function based on
> the current scope the code.
>
>
>
> On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski
> wrote:
>>
>> There is no g defined inside of module X.
>>
>> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  wrote:
>>
>>> julia> module X
>>>export f
>>>function f(x)
>>>g(x)
>>>end
>>>end
>>> X
>>>
>>> julia> module Y
>>>using X
>>>g(x) =  2x
>>>f(4)
>>>end
>>> ERROR: UndefVarError: g not defined
>>>  in f at ./none:4
>>>
>>> I am trying to use another function g(x) which can be defined in any
>>> other module by calling function f.
>>> This is the idea at its simplest. But It seems it doesn't work.
>>>
>>>
>>> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:

 Hi Julia, what are you trying to achieve, concretely?

 On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>
> I started to think, this may be normal working of julia.
>
> import X:_ex_func
> using X
> _ex_func() = println("DDD")
> _1ex_func()
> julia> _1ex_func()
> DDD
> sty
>
> julia> module Y
>   using X
>   _
> _1ex_func  __precompile__  _ex_func
> julia> module Y
>   using X
>   _1ex_func()
>   end
> DDD
> sty
> Y
>
> However, it seems once a function is overridden, it stays overridden
> in every module.
> That is a very weird idea. why is there such a design decision? Can
> someone care to explain it?
>
> Thanks
>
> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>>
>> Guys, this is no solution to my problem,
>>
>> escaping basically tells the the quoted expr to be resolved outside
>> the macro as Lutfullah did. However in my case, escaping a function call
>> doesn't work for some reason.
>> And for that matter, esc should be recursive though...
>>
>>
>> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco
>> wrote:
>>>
>>> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
>>> (mailto:juliatyl...@gmail.com)) wrote:
>>>
>>> > Hi fellows,
>>> >
>>> >
>>> > I was coding a macro, and I am having a prefix issue with
>>> functions.
>>> >
>>> > basically the problem is: Every single one of available functions
>>> (_ex_func) which i want to be globally accessible are prefixed with the
>>> name of the module(X) in which the macro f is defined
>>> >
>>> >
>>> > Here is the code example:
>>> >
>>> > julia> module X
>>> > export @f
>>> > macro f(x)
>>> > st = string("_",x)
>>> > sy = symbol(st)
>>> > esc(quote
>>> > function ($sy)()
>>> > println("st")
>>> > end
>>> >
>>> > function ($(symbol(string("_1",x()
>>> > ($sy)()
>>> > println("sty")
>>> > end
>>> > export $sy
>>> > export $(symbol(string("_1",x)))
>>> > end
>>> > )
>>> > end
>>> > @eval @f ex_func
>>> > end
>>> > X
>>> >
>>> > julia> using X
>>> >
>>> > julia> _
>>> >
>>> > _1ex_func __precompile__ _ex_func
>>> > julia> _1ex_func.env.defs.func.code
>>> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin #
>>> none, line 12:
>>> > (X._ex_func)() # none, line 13: # i want this to be not prefixed
>>> by X
>>> > return (X.println)("sty")
>>> > end)
>>> >
>>> > julia> macroexpand(:(@f ex_func))
>>> > quote # none, line 7:
>>> > function _ex_func() # none, line 8:
>>> > println("st")
>>> > end # none, line 11:

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

I know, but would it be possible to generate code in module X, using g as a 
globally defined function so that the function g gets resolved based on the 
module where f is being used?

Ps: I don't want to pass g as a parameter to f. 

Here is an example:

julia> module X
  export f
  g(x) = 2x
  f(x) = g(x)
  end
X

julia> module Y
  using X
  g(x) = 3x
  println(f(4))
  end
8 *# this should have been 12 if the function g is used from Y, it hasn't 
been used because when we look at the AST, we would see it is making a call 
to the function g in module X.*
Y

julia> f.env.defs.func.code
AST(:($(Expr(:lambda, Any[:x], Any[Any[Any[:x,:Any,0]],Any[],0,Any[]], 
:(begin  # none, line 4:
*return (X.g)(x) # here*
end)

So in the light of this, is it possible to generate code using a macro with 
some sort of a special AST node, which resolves the function based on the 
current scope the code.



On Wednesday, February 17, 2016 at 1:24:33 PM UTC-8, Stefan Karpinski wrote:
>
> There is no g defined inside of module X.
>
> On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  > wrote:
>
>> julia> module X
>>export f
>>function f(x)
>>g(x)
>>end
>>end
>> X
>>
>> julia> module Y
>>using X
>>g(x) =  2x
>>f(4)
>>end
>> ERROR: UndefVarError: g not defined
>>  in f at ./none:4
>>
>> I am trying to use another function g(x) which can be defined in any 
>> other module by calling function f.
>> This is the idea at its simplest. But It seems it doesn't work.
>>
>>
>> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:
>>>
>>> Hi Julia, what are you trying to achieve, concretely? 
>>>
>>> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:

 I started to think, this may be normal working of julia.

 import X:_ex_func
 using X
 _ex_func() = println("DDD")
 _1ex_func()
 julia> _1ex_func()
 DDD
 sty

 julia> module Y
   using X
   _
 _1ex_func  __precompile__  _ex_func
 julia> module Y
   using X
   _1ex_func()
   end
 DDD
 sty
 Y

 However, it seems once a function is overridden, it stays overridden in 
 every module.
 That is a very weird idea. why is there such a design decision? Can 
 someone care to explain it?

 Thanks

 On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>
> Guys, this is no solution to my problem, 
>
> escaping basically tells the the quoted expr to be resolved outside 
> the macro as Lutfullah did. However in my case, escaping a function call 
> doesn't work for some reason.
> And for that matter, esc should be recursive though...
>
>
> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco 
> wrote:
>>
>> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
>> (mailto:juliatyl...@gmail.com)) wrote: 
>>
>> > Hi fellows,   
>> >   
>> >   
>> > I was coding a macro, and I am having a prefix issue with 
>> functions.   
>> >   
>> > basically the problem is: Every single one of available functions 
>> (_ex_func) which i want to be globally accessible are prefixed with the 
>> name of the module(X) in which the macro f is defined   
>> >   
>> >   
>> > Here is the code example:   
>> >   
>> > julia> module X   
>> > export @f 
>> > macro f(x) 
>> > st = string("_",x) 
>> > sy = symbol(st) 
>> > esc(quote 
>> > function ($sy)() 
>> > println("st") 
>> > end 
>> >   
>> > function ($(symbol(string("_1",x()   
>> > ($sy)() 
>> > println("sty") 
>> > end 
>> > export $sy 
>> > export $(symbol(string("_1",x))) 
>> > end 
>> > ) 
>> > end 
>> > @eval @f ex_func 
>> > end 
>> > X 
>> >   
>> > julia> using X   
>> >   
>> > julia> _   
>> >   
>> > _1ex_func __precompile__ _ex_func   
>> > julia> _1ex_func.env.defs.func.code 
>> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # 
>> none, line 12: 
>> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by 
>> X 
>> > return (X.println)("sty") 
>> > end) 
>> >   
>> > julia> macroexpand(:(@f ex_func))   
>> > quote # none, line 7: 
>> > function _ex_func() # none, line 8: 
>> > println("st") 
>> > end # none, line 11: 
>> > function _1ex_func() # none, line 12: 
>> > _ex_func() # none, line 13: # it seems OK, here!!! 
>> > println("sty") 
>> > end # none, line 15: 
>> > export _ex_func # none, line 16: 
>> > export _1ex_func 
>> > 

Re: [julia-users] Re: Unitful.jl for physical units

[Jeffrey Sarnoff]

Jake,

It would be helpful to know more clearly what is the "this" that you are 
experimenting with "ways to achieve this"?  
I took a glance at your code, and one thing that is happening is you have 
left some low-hanging abstraction on the table.  That constrains Julia's 
ability to simplify through organized multidispatch.  I will give it more 
than a glance overnight -- pretend it all works perfectly, show me what you 
want to do with it then.
   

On Wednesday, February 17, 2016 at 3:59:15 PM UTC-5, Jake Rosoman wrote:
>
> Oh yup I thought that was the case but wanted to check. 
>
> I've started experimenting with ways to achieve this but I am getting 
> massive amounts of code generated compared to Unitful. I just uploaded 
> uploaded my work so far at https://GitHub.com/jkroso/units.jl. If anyone 
> could help explain the difference in code gen that would be great and I'll 
> try contribute back to Unitful
> On Thu, 18 Feb 2016 at 7:02 AM Andrew Keller  > wrote:
>
>> Hi Jake,
>>
>> I agree with Jeffrey's response mostly, but want to clarify that Unitful 
>> is not strictly focused on the SI system. You'll see that you can use units 
>> of acre-feet, very much not an SI unit, which could be useful if you happen 
>> to manage a water reservoir in the United States, I guess.
>>
>> If you were instead asking whether or not you could write methods that 
>> dispatch on the dimensions of a unit, the current answer is no, although 
>> maybe that could change eventually.
>>
>> Best,
>> Andrew
>>
>> On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff 
>> wrote:
>>>
>>> Jake,
>>>
>>> Julia's type system is well suited to do just that.  Unitful is focused 
>>> on units in SI system, things like Meters, Kilograms and Joules.
>>>
>>> One approach to abstract units like size, where size may be relative to 
>>> the number of pixels on a screen or the width of a page,
>>> is define your own type, a kind of size relative to something.  In your 
>>> example, s is not a unit of measure (strictly speaking);
>>> s is a quantity interpreted in terms of some absolute or relative unit 
>>> of measure -- 5 pixels, 1/4 page.  Because pixels and pages
>>> are not always the same number of, say, millimeters, using SI units for 
>>> that abstraction likely is not what you want.
>>>
>>> If you want more guidance, please give some more context.
>>>
>>> On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman wrote:

 Is it possible to talk about abstract types of units like size. e.g 
 `drawline(s::Size) = ...`?

 On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller 
 wrote:
>
> I'm happy to share a package I wrote for using physical units in 
> Julia, Unitful.jl . 
> Much credit and gratitude is due to Keno Fischer for the SIUnits.jl 
>  package which served as my 
> inspiration. This is a work in progress, but I think perhaps a 
> serviceable 
> one depending on what you're doing. 
>
> Like SIUnits.jl, this package encodes units in the type signature to 
> avoid run-time performance penalties. From there, the implementations 
> diverge. The package is targeted to Julia 0.5 / master, as there are some 
> limitations with how promote_op is used in Julia 0.4 (#13803) 
> . I decided it wasn't 
> worth targeting 0.4 if the behavior would be inconsistent. 
>
> Some highlights include:
>
>- Non-SI units are treated on the same footing as SI units, with 
>only a few exceptions (unit conversion method). Use whatever weird 
>units you want.
>- Support for units like micron / (meter Kelvin), where some of 
>the units could cancel out but you don't necessarily want them to.
>- Support for LinSpace and other Range types. Probably there are 
>still some glitches to be found, though.
>- Support for rational exponents of units.
>- Some tests (see these for usage examples).
>
> Please see the documentation for a comprehensive discussion, including 
> issues / to do list, as well as how to add your own units, etc.
> Comments and feedback are welcome.
>
> Best,
> Andrew Keller
>

Re: [julia-users] Weird Hygiene Issue

[Stefan Karpinski]

There is no g defined inside of module X.

On Wed, Feb 17, 2016 at 3:19 PM, Julia Tylors  wrote:

> julia> module X
>export f
>function f(x)
>g(x)
>end
>end
> X
>
> julia> module Y
>using X
>g(x) =  2x
>f(4)
>end
> ERROR: UndefVarError: g not defined
>  in f at ./none:4
>
> I am trying to use another function g(x) which can be defined in any other
> module by calling function f.
> This is the idea at its simplest. But It seems it doesn't work.
>
>
> On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:
>>
>> Hi Julia, what are you trying to achieve, concretely?
>>
>> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>>>
>>> I started to think, this may be normal working of julia.
>>>
>>> import X:_ex_func
>>> using X
>>> _ex_func() = println("DDD")
>>> _1ex_func()
>>> julia> _1ex_func()
>>> DDD
>>> sty
>>>
>>> julia> module Y
>>>   using X
>>>   _
>>> _1ex_func  __precompile__  _ex_func
>>> julia> module Y
>>>   using X
>>>   _1ex_func()
>>>   end
>>> DDD
>>> sty
>>> Y
>>>
>>> However, it seems once a function is overridden, it stays overridden in
>>> every module.
>>> That is a very weird idea. why is there such a design decision? Can
>>> someone care to explain it?
>>>
>>> Thanks
>>>
>>> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:

 Guys, this is no solution to my problem,

 escaping basically tells the the quoted expr to be resolved outside the
 macro as Lutfullah did. However in my case, escaping a function call
 doesn't work for some reason.
 And for that matter, esc should be recursive though...


 On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:
>
> On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
> (mailto:juliatyl...@gmail.com)) wrote:
>
> > Hi fellows,
> >
> >
> > I was coding a macro, and I am having a prefix issue with functions.
>
> >
> > basically the problem is: Every single one of available functions
> (_ex_func) which i want to be globally accessible are prefixed with the
> name of the module(X) in which the macro f is defined
> >
> >
> > Here is the code example:
> >
> > julia> module X
> > export @f
> > macro f(x)
> > st = string("_",x)
> > sy = symbol(st)
> > esc(quote
> > function ($sy)()
> > println("st")
> > end
> >
> > function ($(symbol(string("_1",x()
> > ($sy)()
> > println("sty")
> > end
> > export $sy
> > export $(symbol(string("_1",x)))
> > end
> > )
> > end
> > @eval @f ex_func
> > end
> > X
> >
> > julia> using X
> >
> > julia> _
> >
> > _1ex_func __precompile__ _ex_func
> > julia> _1ex_func.env.defs.func.code
> > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin #
> none, line 12:
> > (X._ex_func)() # none, line 13: # i want this to be not prefixed by
> X
> > return (X.println)("sty")
> > end)
> >
> > julia> macroexpand(:(@f ex_func))
> > quote # none, line 7:
> > function _ex_func() # none, line 8:
> > println("st")
> > end # none, line 11:
> > function _1ex_func() # none, line 12:
> > _ex_func() # none, line 13: # it seems OK, here!!!
> > println("sty")
> > end # none, line 15:
> > export _ex_func # none, line 16:
> > export _1ex_func
> > end
> >
> >
> >
> > as you may see , I may well define _ex_func in other modules and use
> it from the function X._1ex_func().
> > But this prevents me doing it.
> >
> > How can i solve this problem?
> >
> > Thanks
>
> OH! I know this!
>
> Actually, I do believe this is a bug in macro hygiene and have been
> meaning to file it. In the mean time, double-escaping should work for you:
>
> julia> module X
>macro p(y)
>  quote
>println($y)
>  end
>end
>macro q(y)
>  quote
>println(:($($y)))
>  end
>end
>end
> X
>
> julia> using X
>
> julia> test = "Hello, world"
> "Hello, world"
>
> julia> @X.p(test)
> ERROR: UndefVarError: test not defined
>
> julia> @X.q(test)
> Hello, world
>

Re: [julia-users] Re: Blog-post on how to make package documentation

[Mauro]

Mike and Tom, thanks!  And yes, the other Mike needs mentioning too, I
updated that footnote.

On Wed, 2016-02-17 at 17:44, Michael Hatherly  wrote:
> Thanks for writing that up Mauro and also the shout-out :) Worth noting
> Mike Innes' important work in getting the docsystem integrated into `Base`
> and his
> heroic effort converting most of the docs from rst to markdown as well.
>
> On a technical note, Lexicon doesn't actually use the docsystem in `Base`
> at all and still relies on Docile's own implementation currently, so it's
> possible
> that people may start to run into problems with this approach on 0.5 as it
> further diverges from 0.3/0.4. (Do open issues if they happen to crop up
> though and I'll do my best to keep things working as long as possible.)
> Future work using the `Base` docsystem for documentation generation is
> moving
> ahead, when time allows, in a separate
> package, https://github.com/MichaelHatherly/Lapidary.jl.
>
> -- Mike
>
> On Wednesday, 17 February 2016 17:13:38 UTC+2, Mauro wrote:
>>
>> Until a few days ago, I was a bit confused on how to go about writing
>> nice package documentation, including API-docs.  I figured it out and it
>> turned out to be pretty trivial, once I knew how.  I wrote it up in case
>> someone else is confused (or I become confused again):
>> http://maurow.bitbucket.org/notes/documenting-a-julia-package.html
>> (feedback welcome)
>>
>>   Mauro
>>

Re: [julia-users] Re: Unitful.jl for physical units

[Jake Rosoman]

Oh yup I thought that was the case but wanted to check.

I've started experimenting with ways to achieve this but I am getting
massive amounts of code generated compared to Unitful. I just uploaded
uploaded my work so far at https://GitHub.com/jkroso/units.jl. If anyone
could help explain the difference in code gen that would be great and I'll
try contribute back to Unitful
On Thu, 18 Feb 2016 at 7:02 AM Andrew Keller 
wrote:

> Hi Jake,
>
> I agree with Jeffrey's response mostly, but want to clarify that Unitful
> is not strictly focused on the SI system. You'll see that you can use units
> of acre-feet, very much not an SI unit, which could be useful if you happen
> to manage a water reservoir in the United States, I guess.
>
> If you were instead asking whether or not you could write methods that
> dispatch on the dimensions of a unit, the current answer is no, although
> maybe that could change eventually.
>
> Best,
> Andrew
>
> On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff wrote:
>>
>> Jake,
>>
>> Julia's type system is well suited to do just that.  Unitful is focused
>> on units in SI system, things like Meters, Kilograms and Joules.
>>
>> One approach to abstract units like size, where size may be relative to
>> the number of pixels on a screen or the width of a page,
>> is define your own type, a kind of size relative to something.  In your
>> example, s is not a unit of measure (strictly speaking);
>> s is a quantity interpreted in terms of some absolute or relative unit of
>> measure -- 5 pixels, 1/4 page.  Because pixels and pages
>> are not always the same number of, say, millimeters, using SI units for
>> that abstraction likely is not what you want.
>>
>> If you want more guidance, please give some more context.
>>
>> On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman wrote:
>>>
>>> Is it possible to talk about abstract types of units like size. e.g
>>> `drawline(s::Size) = ...`?
>>>
>>> On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller wrote:

 I'm happy to share a package I wrote for using physical units in Julia,
 Unitful.jl . Much credit
 and gratitude is due to Keno Fischer for the SIUnits.jl
  package which served as my
 inspiration. This is a work in progress, but I think perhaps a serviceable
 one depending on what you're doing.

 Like SIUnits.jl, this package encodes units in the type signature to
 avoid run-time performance penalties. From there, the implementations
 diverge. The package is targeted to Julia 0.5 / master, as there are some
 limitations with how promote_op is used in Julia 0.4 (#13803)
 . I decided it wasn't
 worth targeting 0.4 if the behavior would be inconsistent.

 Some highlights include:

- Non-SI units are treated on the same footing as SI units, with
only a few exceptions (unit conversion method). Use whatever weird
units you want.
- Support for units like micron / (meter Kelvin), where some of the
units could cancel out but you don't necessarily want them to.
- Support for LinSpace and other Range types. Probably there are
still some glitches to be found, though.
- Support for rational exponents of units.
- Some tests (see these for usage examples).

 Please see the documentation for a comprehensive discussion, including
 issues / to do list, as well as how to add your own units, etc.
 Comments and feedback are welcome.

 Best,
 Andrew Keller

>>>

Re: [julia-users] Weird Hygiene Issue

[Julia Tylors]

julia> module X
   export f
   function f(x)
   g(x)
   end
   end
X

julia> module Y
   using X
   g(x) =  2x
   f(4)
   end
ERROR: UndefVarError: g not defined
 in f at ./none:4

I am trying to use another function g(x) which can be defined in any other 
module by calling function f.
This is the idea at its simplest. But It seems it doesn't work.

On Monday, February 15, 2016 at 7:03:54 PM UTC-8, Cedric St-Jean wrote:
>
> Hi Julia, what are you trying to achieve, concretely? 
>
> On Monday, February 15, 2016 at 2:36:15 PM UTC-5, Julia Tylors wrote:
>>
>> I started to think, this may be normal working of julia.
>>
>> import X:_ex_func
>> using X
>> _ex_func() = println("DDD")
>> _1ex_func()
>> julia> _1ex_func()
>> DDD
>> sty
>>
>> julia> module Y
>>   using X
>>   _
>> _1ex_func  __precompile__  _ex_func
>> julia> module Y
>>   using X
>>   _1ex_func()
>>   end
>> DDD
>> sty
>> Y
>>
>> However, it seems once a function is overridden, it stays overridden in 
>> every module.
>> That is a very weird idea. why is there such a design decision? Can 
>> someone care to explain it?
>>
>> Thanks
>>
>> On Monday, February 15, 2016 at 11:04:07 AM UTC-8, Julia Tylors wrote:
>>>
>>> Guys, this is no solution to my problem, 
>>>
>>> escaping basically tells the the quoted expr to be resolved outside the 
>>> macro as Lutfullah did. However in my case, escaping a function call 
>>> doesn't work for some reason.
>>> And for that matter, esc should be recursive though...
>>>
>>>
>>> On Monday, February 15, 2016 at 6:44:58 AM UTC-8, Joshua Ballanco wrote:

 On February 14, 2016 at 21:49:30, Julia Tylors (julia...@gmail.com
 (mailto:juliatyl...@gmail.com)) wrote: 

 > Hi fellows,   
 >   
 >   
 > I was coding a macro, and I am having a prefix issue with functions. 
   
 >   
 > basically the problem is: Every single one of available functions 
 (_ex_func) which i want to be globally accessible are prefixed with the 
 name of the module(X) in which the macro f is defined   
 >   
 >   
 > Here is the code example:   
 >   
 > julia> module X   
 > export @f 
 > macro f(x) 
 > st = string("_",x) 
 > sy = symbol(st) 
 > esc(quote 
 > function ($sy)() 
 > println("st") 
 > end 
 >   
 > function ($(symbol(string("_1",x()   
 > ($sy)() 
 > println("sty") 
 > end 
 > export $sy 
 > export $(symbol(string("_1",x))) 
 > end 
 > ) 
 > end 
 > @eval @f ex_func 
 > end 
 > X 
 >   
 > julia> using X   
 >   
 > julia> _   
 >   
 > _1ex_func __precompile__ _ex_func   
 > julia> _1ex_func.env.defs.func.code 
 > AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin # 
 none, line 12: 
 > (X._ex_func)() # none, line 13: # i want this to be not prefixed by X 
 > return (X.println)("sty") 
 > end) 
 >   
 > julia> macroexpand(:(@f ex_func))   
 > quote # none, line 7: 
 > function _ex_func() # none, line 8: 
 > println("st") 
 > end # none, line 11: 
 > function _1ex_func() # none, line 12: 
 > _ex_func() # none, line 13: # it seems OK, here!!! 
 > println("sty") 
 > end # none, line 15: 
 > export _ex_func # none, line 16: 
 > export _1ex_func 
 > end 
 >   
 >   
 >   
 > as you may see , I may well define _ex_func in other modules and use 
 it from the function X._1ex_func().   
 > But this prevents me doing it. 
 >   
 > How can i solve this problem?   
 >   
 > Thanks 

 OH! I know this! 

 Actually, I do believe this is a bug in macro hygiene and have been 
 meaning to file it. In the mean time, double-escaping should work for you: 

 julia> module X 
macro p(y) 
  quote 
println($y) 
  end 
end 
macro q(y) 
  quote 
println(:($($y))) 
  end 
end 
end 
 X 
  
 julia> using X 
  
 julia> test = "Hello, world" 
 "Hello, world" 
  
 julia> @X.p(test) 
 ERROR: UndefVarError: test not defined 
  
 julia> @X.q(test) 
 Hello, world 

>>>

Re: [julia-users] Options for constructing a 3D surface from a point cloud

[Chris]

You're right, of course -- I'm sort of learning about the published methods 
while at the same time searching for implementations. For instance, the 
reason I mentioned Meshes is that I saw it had an implementation of the 
marching cubes algorithm, and I was hoping it might be easy enough to 
quickly try a test case.

On Wednesday, February 17, 2016 at 10:05:44 AM UTC-8, Tamas Papp wrote:
>
> This is not a Julia-specific problem: you need to decide what algorithm 
> to use, which depends on what you know about your surface. 
>
> Eg if it is a function f(x,y), and reasonably smooth and differentiable 
> over some domain, you can use a family of basis functions to interpolate 
> -- see ApproxFun.jl. If it is some more general surface, you would need 
> other algorithms or transformations; there are no general ones (this is 
> the nature of the problem) and you will need to make some assumptions. 
>
> Best, 
>
> Tamas 
>
> On Wed, Feb 17 2016, Chris wrote: 
>
> > If I have a set of 3D points, randomly sampled from some arbitrary 
> surface, 
> > what are my options (in terms of Julia packages) for reconstructing the 
> > surface for plotting? I've done a little research and found the 
> Meshes.jl 
> > package, but I can't find any good examples or documentation for it. In 
> > case it's not already obvious, I'm completely new to this topic, so any 
> > direction would be appreciated. 
> > 
> > Thanks, 
> > Chris 
>
>

Re: [julia-users] Options for constructing a 3D surface from a point cloud

[Tamas Papp]

This is not a Julia-specific problem: you need to decide what algorithm
to use, which depends on what you know about your surface.

Eg if it is a function f(x,y), and reasonably smooth and differentiable
over some domain, you can use a family of basis functions to interpolate
-- see ApproxFun.jl. If it is some more general surface, you would need
other algorithms or transformations; there are no general ones (this is
the nature of the problem) and you will need to make some assumptions.

Best,

Tamas

On Wed, Feb 17 2016, Chris wrote:

> If I have a set of 3D points, randomly sampled from some arbitrary surface, 
> what are my options (in terms of Julia packages) for reconstructing the 
> surface for plotting? I've done a little research and found the Meshes.jl 
> package, but I can't find any good examples or documentation for it. In 
> case it's not already obvious, I'm completely new to this topic, so any 
> direction would be appreciated.
>
> Thanks,
> Chris

[julia-users] Re: Unitful.jl for physical units

[Andrew Keller]

Hi Jake,

I agree with Jeffrey's response mostly, but want to clarify that Unitful is 
not strictly focused on the SI system. You'll see that you can use units of 
acre-feet, very much not an SI unit, which could be useful if you happen to 
manage a water reservoir in the United States, I guess.

If you were instead asking whether or not you could write methods that 
dispatch on the dimensions of a unit, the current answer is no, although 
maybe that could change eventually.

Best,
Andrew

On Wednesday, February 17, 2016 at 3:25:37 AM UTC-8, Jeffrey Sarnoff wrote:
>
> Jake,
>
> Julia's type system is well suited to do just that.  Unitful is focused on 
> units in SI system, things like Meters, Kilograms and Joules.
>
> One approach to abstract units like size, where size may be relative to 
> the number of pixels on a screen or the width of a page,
> is define your own type, a kind of size relative to something.  In your 
> example, s is not a unit of measure (strictly speaking);
> s is a quantity interpreted in terms of some absolute or relative unit of 
> measure -- 5 pixels, 1/4 page.  Because pixels and pages
> are not always the same number of, say, millimeters, using SI units for 
> that abstraction likely is not what you want.
>
> If you want more guidance, please give some more context.
>
> On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman wrote:
>>
>> Is it possible to talk about abstract types of units like size. e.g 
>> `drawline(s::Size) = ...`?
>>
>> On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller wrote:
>>>
>>> I'm happy to share a package I wrote for using physical units in Julia, 
>>> Unitful.jl . Much credit 
>>> and gratitude is due to Keno Fischer for the SIUnits.jl 
>>>  package which served as my 
>>> inspiration. This is a work in progress, but I think perhaps a serviceable 
>>> one depending on what you're doing. 
>>>
>>> Like SIUnits.jl, this package encodes units in the type signature to 
>>> avoid run-time performance penalties. From there, the implementations 
>>> diverge. The package is targeted to Julia 0.5 / master, as there are some 
>>> limitations with how promote_op is used in Julia 0.4 (#13803) 
>>> . I decided it wasn't 
>>> worth targeting 0.4 if the behavior would be inconsistent. 
>>>
>>> Some highlights include:
>>>
>>>- Non-SI units are treated on the same footing as SI units, with 
>>>only a few exceptions (unit conversion method). Use whatever weird 
>>>units you want.
>>>- Support for units like micron / (meter Kelvin), where some of the 
>>>units could cancel out but you don't necessarily want them to.
>>>- Support for LinSpace and other Range types. Probably there are 
>>>still some glitches to be found, though.
>>>- Support for rational exponents of units.
>>>- Some tests (see these for usage examples).
>>>
>>> Please see the documentation for a comprehensive discussion, including 
>>> issues / to do list, as well as how to add your own units, etc.
>>> Comments and feedback are welcome.
>>>
>>> Best,
>>> Andrew Keller
>>>
>>

[julia-users] Re: Options for constructing a 3D surface from a point cloud

[J Luis]

It is not yet registered but you can use GMT 
, namely its module 'surface' to do a 
minimum curvature interpolation (but other algorithms are available as 
well).

quarta-feira, 17 de Fevereiro de 2016 às 17:46:57 UTC, Chris escreveu:
>
> If I have a set of 3D points, randomly sampled from some arbitrary 
> surface, what are my options (in terms of Julia packages) for 
> reconstructing the surface for plotting? I've done a little research and 
> found the Meshes.jl package, but I can't find any good examples or 
> documentation for it. In case it's not already obvious, I'm completely new 
> to this topic, so any direction would be appreciated.
>
> Thanks,
> Chris
>

Re: [julia-users] Is this a 0.5 bug?

[Josh Langsfeld]

Whoops, sorry Yichao, I missed you had already given the suggested change.

On Wednesday, February 17, 2016 at 10:30:54 AM UTC-5, Yichao Yu wrote:
>
> On Wed, Feb 17, 2016 at 10:22 AM, J Luis  
> wrote: 
> > Hi, see 
> > 
> > function ttt() 
> > t1 = [-1167.3955469319576 9.9]; 
> > t2 = [-1170.4689400259758 -15.31]; 
> > t = [t1[1,:]; t2[1,:]] 
> > @show(t1,t2,t) 
> > end 
> > 
> > prints on 0.4 
> > 
> > t1 = [-1167.3955469319576 9.9] 
> > t2 = [-1170.4689400259758 -15.31] 
> > t = [-1167.3955469319576 9.9 
> >  -1170.4689400259758 -15.31] 
> > 2x2 Array{Float64,2}: 
> >  -1167.4 9.9 
> >  -1170.47  -15.31 
> > 
> > but on 0.5 (built yesterday) 
> > 
> > t1 = [-1167.3955469319576 9.9] 
> > t2 = [-1170.4689400259758 -15.31] 
> > t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31] 
> > 4-element Array{Float64,1}: 
> >  -1167.4 
> >  9.9 
> >  -1170.47 
> >-15.31 
>
> IIUC this is an intentional change 
> https://github.com/JuliaLang/julia/pull/13612. 
>
> An easy way to fix the compatibility on 0.4 and 0.5 is to use 1:1 instead 
> of 1. 
>

Re: [julia-users] Is this a 0.5 bug?

[Josh Langsfeld]

To get a two-dimensional output array (i.e., row vector), you can use a 
non-scalar indexing expression such as t1[[1],:] or t1[1:1,:].

You probably knew this already, but just making a note for any others 
reading who might not.

On Wednesday, February 17, 2016 at 10:51:04 AM UTC-5, J Luis wrote:

Ok, thanks. Surprising for Matlab users but ok.
>
> quarta-feira, 17 de Fevereiro de 2016 às 15:30:54 UTC, Yichao Yu escreveu:
>>
>> On Wed, Feb 17, 2016 at 10:22 AM, J Luis  wrote: 
>> > Hi, see 
>> > 
>> > function ttt() 
>> > t1 = [-1167.3955469319576 9.9]; 
>> > t2 = [-1170.4689400259758 -15.31]; 
>> > t = [t1[1,:]; t2[1,:]] 
>> > @show(t1,t2,t) 
>> > end 
>> > 
>> > prints on 0.4 
>> > 
>> > t1 = [-1167.3955469319576 9.9] 
>> > t2 = [-1170.4689400259758 -15.31] 
>> > t = [-1167.3955469319576 9.9 
>> >  -1170.4689400259758 -15.31] 
>> > 2x2 Array{Float64,2}: 
>> >  -1167.4 9.9 
>> >  -1170.47  -15.31 
>> > 
>> > but on 0.5 (built yesterday) 
>> > 
>> > t1 = [-1167.3955469319576 9.9] 
>> > t2 = [-1170.4689400259758 -15.31] 
>> > t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31] 
>> > 4-element Array{Float64,1}: 
>> >  -1167.4 
>> >  9.9 
>> >  -1170.47 
>> >-15.31 
>>
>> IIUC this is an intentional change 
>> https://github.com/JuliaLang/julia/pull/13612. 
>>
>> An easy way to fix the compatibility on 0.4 and 0.5 is to use 1:1 instead 
>> of 1. 
>>
> ​

[julia-users] Options for constructing a 3D surface from a point cloud

[Chris]

If I have a set of 3D points, randomly sampled from some arbitrary surface, 
what are my options (in terms of Julia packages) for reconstructing the 
surface for plotting? I've done a little research and found the Meshes.jl 
package, but I can't find any good examples or documentation for it. In 
case it's not already obvious, I'm completely new to this topic, so any 
direction would be appreciated.

Thanks,
Chris

[julia-users] Re: Blog-post on how to make package documentation

[Michael Hatherly]

Thanks for writing that up Mauro and also the shout-out :) Worth noting 
Mike Innes' important work in getting the docsystem integrated into `Base` 
and his
heroic effort converting most of the docs from rst to markdown as well.

On a technical note, Lexicon doesn't actually use the docsystem in `Base` 
at all and still relies on Docile's own implementation currently, so it's 
possible
that people may start to run into problems with this approach on 0.5 as it 
further diverges from 0.3/0.4. (Do open issues if they happen to crop up
though and I'll do my best to keep things working as long as possible.) 
Future work using the `Base` docsystem for documentation generation is 
moving
ahead, when time allows, in a separate 
package, https://github.com/MichaelHatherly/Lapidary.jl.

-- Mike

On Wednesday, 17 February 2016 17:13:38 UTC+2, Mauro wrote:
>
> Until a few days ago, I was a bit confused on how to go about writing 
> nice package documentation, including API-docs.  I figured it out and it 
> turned out to be pretty trivial, once I knew how.  I wrote it up in case 
> someone else is confused (or I become confused again): 
> http://maurow.bitbucket.org/notes/documenting-a-julia-package.html 
> (feedback welcome) 
>
>   Mauro 
>

[julia-users] Re: Implicit constructor for custom types through Base.convert

[Helge Eichhorn]

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

Am Dienstag, 16. Februar 2016 22:54:54 UTC+1 schrieb Cedric St-Jean:
>
> That looks like a bug to me. I couldn't find any github issue covering it, 
> maybe you should submit one? 
>
> On Tuesday, February 16, 2016 at 10:01:05 AM UTC-5, Helge Eichhorn wrote:
>>
>> When I run the following code
>>
>> type A
>> v::Float64
>> end
>>
>> type B
>> v::Float64
>> end
>>
>> Base.convert(::Type{A}, b::B) = A(b.v/2)
>> b = B(12)
>> A(b)
>>
>> it fails with this error message because the implicit constructor is 
>> called.
>>
>> LoadError: MethodError: `convert` has no method matching 
>> convert(::Type{Float64}, ::B)
>> This may have arisen from a call to the constructor Float64(...),
>> since type constructors fall back to convert methods.
>> Closest candidates are:
>>   call{T}(::Type{T}, ::Any)
>>   convert(::Type{Float64}, !Matched::Int8)
>>   convert(::Type{Float64}, !Matched::Int16)
>>   ...
>> while loading In[1], in expression starting on line 11
>>
>>  in call at In[1]:2
>>
>>
>> Since the manual said "defining Base.convert(::Type{T}, args...) = 
>> ...automatically 
>> defines a constructor T(args...) = ", I expected this to work.
>> If I define a convert method for a built-in type like Float64, it works. 
>> Am I doing something wrong or is this intended? If so, it should be clearly 
>> stated in the manual.
>>
>

Re: [julia-users] Blog-post on how to make package documentation

[Tom Breloff]

Thanks for this Mauro... I bookmarked the page, as I'm sure I'll come back
to reference it many times.

On Wed, Feb 17, 2016 at 10:13 AM, Mauro  wrote:

> Until a few days ago, I was a bit confused on how to go about writing
> nice package documentation, including API-docs.  I figured it out and it
> turned out to be pretty trivial, once I knew how.  I wrote it up in case
> someone else is confused (or I become confused again):
> http://maurow.bitbucket.org/notes/documenting-a-julia-package.html
> (feedback welcome)
>
>   Mauro
>

Re: [julia-users] Is this a 0.5 bug?

[J Luis]

Ok, thanks. Surprising for Matlab users but ok.

quarta-feira, 17 de Fevereiro de 2016 às 15:30:54 UTC, Yichao Yu escreveu:
>
> On Wed, Feb 17, 2016 at 10:22 AM, J Luis  
> wrote: 
> > Hi, see 
> > 
> > function ttt() 
> > t1 = [-1167.3955469319576 9.9]; 
> > t2 = [-1170.4689400259758 -15.31]; 
> > t = [t1[1,:]; t2[1,:]] 
> > @show(t1,t2,t) 
> > end 
> > 
> > prints on 0.4 
> > 
> > t1 = [-1167.3955469319576 9.9] 
> > t2 = [-1170.4689400259758 -15.31] 
> > t = [-1167.3955469319576 9.9 
> >  -1170.4689400259758 -15.31] 
> > 2x2 Array{Float64,2}: 
> >  -1167.4 9.9 
> >  -1170.47  -15.31 
> > 
> > but on 0.5 (built yesterday) 
> > 
> > t1 = [-1167.3955469319576 9.9] 
> > t2 = [-1170.4689400259758 -15.31] 
> > t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31] 
> > 4-element Array{Float64,1}: 
> >  -1167.4 
> >  9.9 
> >  -1170.47 
> >-15.31 
>
> IIUC this is an intentional change 
> https://github.com/JuliaLang/julia/pull/13612. 
>
> An easy way to fix the compatibility on 0.4 and 0.5 is to use 1:1 instead 
> of 1. 
>

[julia-users] Re: Is this a 0.5 bug?

[Kristoffer Carlsson]

Probably https://github.com/JuliaLang/julia/pull/13612

On Wednesday, February 17, 2016 at 4:22:40 PM UTC+1, J Luis wrote:
>
> Hi, see
>
> function ttt()
> t1 = [-1167.3955469319576 9.9];
> t2 = [-1170.4689400259758 -15.31];
> t = [t1[1,:]; t2[1,:]]
> @show(t1,t2,t)
> end
>
> prints on 0.4
>
> t1 = [-1167.3955469319576 9.9]
> t2 = [-1170.4689400259758 -15.31]
> t = [-1167.3955469319576 9.9
>  -1170.4689400259758 -15.31]
> 2x2 Array{Float64,2}:
>  -1167.4 9.9
>  -1170.47  -15.31
>
> but on 0.5 (built yesterday)
>
> t1 = [-1167.3955469319576 9.9]
> t2 = [-1170.4689400259758 -15.31]
> t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31]
> 4-element Array{Float64,1}:
>  -1167.4
>  9.9
>  -1170.47
>-15.31
>

Re: [julia-users] Is this a 0.5 bug?

[Yichao Yu]

On Wed, Feb 17, 2016 at 10:22 AM, J Luis  wrote:
> Hi, see
>
> function ttt()
> t1 = [-1167.3955469319576 9.9];
> t2 = [-1170.4689400259758 -15.31];
> t = [t1[1,:]; t2[1,:]]
> @show(t1,t2,t)
> end
>
> prints on 0.4
>
> t1 = [-1167.3955469319576 9.9]
> t2 = [-1170.4689400259758 -15.31]
> t = [-1167.3955469319576 9.9
>  -1170.4689400259758 -15.31]
> 2x2 Array{Float64,2}:
>  -1167.4 9.9
>  -1170.47  -15.31
>
> but on 0.5 (built yesterday)
>
> t1 = [-1167.3955469319576 9.9]
> t2 = [-1170.4689400259758 -15.31]
> t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31]
> 4-element Array{Float64,1}:
>  -1167.4
>  9.9
>  -1170.47
>-15.31

IIUC this is an intentional change
https://github.com/JuliaLang/julia/pull/13612.

An easy way to fix the compatibility on 0.4 and 0.5 is to use 1:1 instead of 1.

[julia-users] Is this a 0.5 bug?

[J Luis]

Hi, see

function ttt()
t1 = [-1167.3955469319576 9.9];
t2 = [-1170.4689400259758 -15.31];
t = [t1[1,:]; t2[1,:]]
@show(t1,t2,t)
end

prints on 0.4

t1 = [-1167.3955469319576 9.9]
t2 = [-1170.4689400259758 -15.31]
t = [-1167.3955469319576 9.9
 -1170.4689400259758 -15.31]
2x2 Array{Float64,2}:
 -1167.4 9.9
 -1170.47  -15.31

but on 0.5 (built yesterday)

t1 = [-1167.3955469319576 9.9]
t2 = [-1170.4689400259758 -15.31]
t = [-1167.3955469319576,9.9,-1170.4689400259758,-15.31]
4-element Array{Float64,1}:
 -1167.4
 9.9
 -1170.47
   -15.31

[julia-users] Re: Easy way to precompile all installed packages?

[Oliver Schulz]

Sure, that kinda works. Unfortunately, it doesn't include site-wide 
packages (resp. packages in LOAD_PATH). Is there a way to list all packages 
that are available to import/using?

On Wednesday, February 17, 2016 at 2:20:21 PM UTC+1, Steven G. Johnson 
wrote:
>
> map(require, keys(Pkg.installed()))
>

[julia-users] Re: Easy way to precompile all installed packages?

[Oliver Schulz]

Also, require gives a deprecation warning. ;-)

On Wednesday, February 17, 2016 at 4:13:22 PM UTC+1, Oliver Schulz wrote:
>
> Sure, that kinda works. Unfortunately, it doesn't include site-wide 
> packages (resp. packages in LOAD_PATH). Is there a way to list all packages 
> that are available to import/using?
>
> On Wednesday, February 17, 2016 at 2:20:21 PM UTC+1, Steven G. Johnson 
> wrote:
>>
>> map(require, keys(Pkg.installed()))
>>
>

[julia-users] Blog-post on how to make package documentation

[Mauro]

Until a few days ago, I was a bit confused on how to go about writing
nice package documentation, including API-docs.  I figured it out and it
turned out to be pretty trivial, once I knew how.  I wrote it up in case
someone else is confused (or I become confused again):
http://maurow.bitbucket.org/notes/documenting-a-julia-package.html
(feedback welcome)

  Mauro

[julia-users] Re: Easy way to precompile all installed packages?

[Steven G. Johnson]

map(require, keys(Pkg.installed()))

[julia-users] Re: Easy way to precompile all installed packages?

[Tom Lee]

I haven't tested this properly, but maybe something like:

req = split( open("$(Pkg.dir())/REQUIRE") do f ; readall(f);end , '\n' )
for pkgstr in req
p = symbol(pkgstr)
@eval using $p
end


PS apologies for the incomplete post before. Very frustrating that typing 
 in a coding block, then  after that doesn't work leads to 
inadvertent posting...

On Wednesday, 17 February 2016 21:58:10 UTC+10, Oliver Schulz wrote:
>
> Is there an easy way to precompile all installed packages, e.g. after a 
> `Pkg.update()`?
>
> This would come in handy when using a cluster of Julia machines (using an 
> shared home dir on a network filesystem), to ensure precompilation is done 
> before all machines load (and start precompiling) packages (e.g. from a 
> shared home directory via a network filesystem).
>
> Also, as precompilation of many packages can take quite a bit of time, it 
> would be nice to be able to choose when it happens (i.e. right now, instead 
> later when I may want to give a tutorial or so ;-) ).
>
> Sorry if this is somewhere in the docs, I didn't find anything about it. 
> I'd love to be able to just do `Pkg.update(precompile = true)` or so.
>
>
> Cheers,
>
> Oliver
>
>

[julia-users] Re: Easy way to precompile all installed packages?

[Tom Lee]

I haven't tested this, but maybe something like:

req = split( open("$(Pkg.dir())/REQUIRE") do f ; readall(f);end , '\n' )
for pkgstr in req





On Wednesday, 17 February 2016 21:58:10 UTC+10, Oliver Schulz wrote:
>
> Is there an easy way to precompile all installed packages, e.g. after a 
> `Pkg.update()`?
>
> This would come in handy when using a cluster of Julia machines (using an 
> shared home dir on a network filesystem), to ensure precompilation is done 
> before all machines load (and start precompiling) packages (e.g. from a 
> shared home directory via a network filesystem).
>
> Also, as precompilation of many packages can take quite a bit of time, it 
> would be nice to be able to choose when it happens (i.e. right now, instead 
> later when I may want to give a tutorial or so ;-) ).
>
> Sorry if this is somewhere in the docs, I didn't find anything about it. 
> I'd love to be able to just do `Pkg.update(precompile = true)` or so.
>
>
> Cheers,
>
> Oliver
>
>

[julia-users] Easy way to precompile all installed packages?

[Oliver Schulz]

Is there an easy way to precompile all installed packages, e.g. after a 
`Pkg.update()`?

This would come in handy when using a cluster of Julia machines (using an 
shared home dir on a network filesystem), to ensure precompilation is done 
before all machines load (and start precompiling) packages (e.g. from a 
shared home directory via a network filesystem).

Also, as precompilation of many packages can take quite a bit of time, it 
would be nice to be able to choose when it happens (i.e. right now, instead 
later when I may want to give a tutorial or so ;-) ).

Sorry if this is somewhere in the docs, I didn't find anything about it. 
I'd love to be able to just do `Pkg.update(precompile = true)` or so.


Cheers,

Oliver

[julia-users] Re: Unitful.jl for physical units

[Jeffrey Sarnoff]

Jake,

Julia's type system is well suited to do just that.  Unitful is focused on 
units in SI system, things like Meters, Kilograms and Joules.

One approach to abstract units like size, where size may be relative to the 
number of pixels on a screen or the width of a page,
is define your own type, a kind of size relative to something.  In your 
example, s is not a unit of measure (strictly speaking);
s is a quantity interpreted in terms of some absolute or relative unit of 
measure -- 5 pixels, 1/4 page.  Because pixels and pages
are not always the same number of, say, millimeters, using SI units for 
that abstraction likely is not what you want.

If you want more guidance, please give some more context.

On Wednesday, February 17, 2016 at 4:43:13 AM UTC-5, Jake Rosoman wrote:
>
> Is it possible to talk about abstract types of units like size. e.g 
> `drawline(s::Size) = ...`?
>
> On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller wrote:
>>
>> I'm happy to share a package I wrote for using physical units in Julia, 
>> Unitful.jl . Much credit 
>> and gratitude is due to Keno Fischer for the SIUnits.jl 
>>  package which served as my 
>> inspiration. This is a work in progress, but I think perhaps a serviceable 
>> one depending on what you're doing. 
>>
>> Like SIUnits.jl, this package encodes units in the type signature to 
>> avoid run-time performance penalties. From there, the implementations 
>> diverge. The package is targeted to Julia 0.5 / master, as there are some 
>> limitations with how promote_op is used in Julia 0.4 (#13803) 
>> . I decided it wasn't 
>> worth targeting 0.4 if the behavior would be inconsistent. 
>>
>> Some highlights include:
>>
>>- Non-SI units are treated on the same footing as SI units, with only 
>>a few exceptions (unit conversion method). Use whatever weird units 
>>you want.
>>- Support for units like micron / (meter Kelvin), where some of the 
>>units could cancel out but you don't necessarily want them to.
>>- Support for LinSpace and other Range types. Probably there are 
>>still some glitches to be found, though.
>>- Support for rational exponents of units.
>>- Some tests (see these for usage examples).
>>
>> Please see the documentation for a comprehensive discussion, including 
>> issues / to do list, as well as how to add your own units, etc.
>> Comments and feedback are welcome.
>>
>> Best,
>> Andrew Keller
>>
>

Re: [julia-users] Cxx.jl object address stability?

[Oliver Schulz]

Thanks, Keno!

Keeping an object on the C++ heap, but having it GC'ed by Julia, would 
probably mean I have to use a unique_ptr or similar, like (as a trivial 
example)

s = icxx""" std::unique_ptr(new std::string("foo")); """;

But then, things like

@cxx s->length()

won't work anymore, obviously. I really like the `@cxx foo->bar()` syntax 
because if work for both objects and pointers, so it's easy to write 
generic code that can take both. Especially for what I'm working on (the 
ROOT interface) that's very handy - ROOT's design is a bit archaic and the 
API uses raw pointers almost everywhere. So I'm try to make that appear 
sane (and be safe) from the Julia side, while keeping things as simple as 
possible.

Hm, maybe it's not too much of a hack if I rely on the current GC 
behaviour, and use pinning if/when it changes?


Cheers,

Oliver


On Wednesday, February 17, 2016 at 4:28:57 AM UTC+1, Keno Fischer wrote:
>
> Sorry, didn't see this before.
>
> The answer is that anything of type CppValue will be owned by julia and 
> destructed upon GC. Right now that should be stable, but I will not 
> guarantee that given future possible directions of the language, so for use 
> cases like this I would recommend keeping the object on the C++ heap so you 
> have explicit control over addresses.
>
> On Thu, Feb 11, 2016 at 7:09 AM, Oliver Schulz  > wrote:
>
>> Hi,
>>
>> is the memory address (seen from C++) of objects created via `@cxx 
>> SomeClass()` (or similar) stable over time (GC cycles)?
>>
>> I need to use a container class whose elements keep a pointer to the 
>> container itself. I want Julia to own the container, so it should be 
>> subject to garbage collection. The container owns it's elements and deletes 
>> them on destruction, so they can't outlive the container object. But 
>> obviously, the address of the container object must not change over time, 
>> else things will break. So is it safe to do
>>
>> container = @cxx Container()
>>
>> or
>>
>> container = icxx""" Container(); """
>>
>> Or do I need to do something like
>>
>> container = icxx""" std::unique_ptr(new Container); """
>>
>> I would assume that "container.data" moves around during GC cycles, so 
>> that `icxx""" &$container """` wouldn't be stable over GC cycles. But 
>> this little test seems to indicate that it actually may be stable:
>>
>> cxx"""
>> struct MyContainer {
>> MyContainer* m_origAddr;
>> MyContainer* origAddr() { return m_origAddr; }
>> MyContainer* currAddr() { return this; }
>> bool checkAddr() { return currAddr() == origAddr(); }
>> MyContainer() { m_origAddr = this; }
>> };
>> """
>>
>> typealias MyContainer 
>> cxxt"MyContainer"{Int(icxx"""sizeof(MyContainer);""")}
>>
>> rndarray = rand(1000,1000,100)
>>
>> containers = Vector{MyContainer}()
>> for i in 1:2000 push!(containers, @cxx MyContainer()) end
>> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>>
>> rndarray = rand(10,10,10)
>> gc()
>>
>> assert(all(x -> icxx""" $x.checkAddr(); """, containers))
>>
>> Keno, help ... ? ;-)
>>
>>
>> Cheers,
>>
>> Oliver
>>
>>
>

[julia-users] Re: Unitful.jl for physical units

[Jake Rosoman]

Is it possible to talk about abstract types of units like size. e.g 
`drawline(s::Size) = ...`?

On Saturday, February 13, 2016 at 9:23:22 AM UTC+13, Andrew Keller wrote:
>
> I'm happy to share a package I wrote for using physical units in Julia, 
> Unitful.jl . Much credit 
> and gratitude is due to Keno Fischer for the SIUnits.jl 
>  package which served as my 
> inspiration. This is a work in progress, but I think perhaps a serviceable 
> one depending on what you're doing. 
>
> Like SIUnits.jl, this package encodes units in the type signature to avoid 
> run-time performance penalties. From there, the implementations diverge. 
> The package is targeted to Julia 0.5 / master, as there are some 
> limitations with how promote_op is used in Julia 0.4 (#13803) 
> . I decided it wasn't 
> worth targeting 0.4 if the behavior would be inconsistent. 
>
> Some highlights include:
>
>- Non-SI units are treated on the same footing as SI units, with only 
>a few exceptions (unit conversion method). Use whatever weird units 
>you want.
>- Support for units like micron / (meter Kelvin), where some of the 
>units could cancel out but you don't necessarily want them to.
>- Support for LinSpace and other Range types. Probably there are still 
>some glitches to be found, though.
>- Support for rational exponents of units.
>- Some tests (see these for usage examples).
>
> Please see the documentation for a comprehensive discussion, including 
> issues / to do list, as well as how to add your own units, etc.
> Comments and feedback are welcome.
>
> Best,
> Andrew Keller
>