Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

On 22 September 2015 at 20:40, Stefan Karpinski 
wrote:

> I think that before any further discussion takes place of how easy or hard
> implementing a high-performance printf is, anyone who'd like to comment
> should spend some time perusing GNU libc's vfprintf implementation
> .
> This code is neither easy nor trivial – it's batsh*t crazy.
>

That is insane... 2388 lines, half of it macros, and I have no idea how it
works.



> And we want to match its performance yet be much more flexible and
> generic. The current printf implementation does just that, while being
> somewhat less insane GNU's printf code. If someone has bright ideas for how
> to *also* allow runtime format specification without sacrificing
> performance or generality, I'm all ears.
>


This might be a stupid question, but what's the harm in sacrificing
performance as long as we keep the current @sprintf for scenarios that call
for performance? I don't always need printf() to be fast.




> I have some thoughts, but they're just that – thoughts. One option is to
> change the design and avoid printf-style formatting altogether. But then
> I'm sure I'll never hear the end of it with people kvetching about how we
> don't have printf.
>

Probably. Everyone is used to printf and they are comfortable with it.

Daniel.

Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

On 22 September 2015 at 17:42, Stefan Karpinski 
wrote:

> Responding with a solicitation for help in an open source project is not a
> rhetorical ploy – it's a legitimate request for contribution.
>

It can be either. It depends on context and intent. I have seen that
comment used both ways. I once saw a seminar that suggested that as a
technique to get rid of people you don't want to deal with (e.g. because
the person is disruptive in some way).


A lecture on the importance of printing numbers is also not helpful and
> pretty irritating. Yes, printing things is important, especially numbers.
> Everyone is well aware, myself included – that's why I spent a month
> implementing our generic printf in the first place. It will get fixed.
>


I don't know if this is a response to me or someone else. I never gave a
lecture on the importance of printing numbers. At least, I never intended
to and I don't know what I said that would come across like that.

Anyway, I appreciate that you are busy with probably more important things,
and I thank you for the work you have already done. My email was harsher
than it should have been, but I was replying comments from Tomas. I was not
trying to file a complaint with the Julia devs. I know that you know about
the @sprintf() issue, and I was not trying to remind you of it. I took
issue with Tomas saying that printf() was not implemented because the devs
were trying to decide what the right implementation should be. I don't
think that this is, or should be, the right reason to not implement
printf(). I suspected that the real reason was, as you said, that there is
more work on your planet than just printf().




> In the mean time, several viable solutions have been provided
> (repeatedly), including...
>

I was not aware of the eval() option, but I was aware of the others. In
particular, I spent a while experimenting with C's printf() function, but I
was not able to make a generic wrapper around it. This means that, for me,
a direct call to C's printf is no more useful than the existing @sprintf
macro. I also compared Formatter.jl with @sprintf and I decided that
@sprintf served me better.



> 2. *Use Formatting.jl.* If you don't care for the interface, help improve
> it. Help could take the form of pull requests, of just polite issues opened
> to suggest how the interface could be enhanced. Calling it "next to
> useless" and dismissing out of hand is rude and not particularly
> constructive.
>

I was rude and I apologize. I don't think that Formatting.jl can be fixed.
I think that there is probably a good reason it only provides sprintf1(). I
don't think it would be news to the developers that a sprintf() that takes
more than one parameter is desirable. If they haven't done it, it is
because they can't.



> 3. *Use C's printf.* Since this seems to be what you want and you can
> easily call C from Julia, what's stopping you?
>
> julia> ccall(:printf, Cint,
>  (Cstring, Cint, Cstring, Cdouble),
>  "%05d %-5s %5.2f\n", 123, "flux", pi)
> 00123 flux   3.14
> 18
>
>
> It's not the most convenient interface in the world, but a little wrapping
> would solve that. (It may also be incorrect since printf is a varargs
> function – I was a little surprised that it worked – but using vprintf
> would address that.)
>

Yes, this is the approach I tried to work on. I was trying to make a
wrapper. But I was unable to make a generic one. Similar to the @eval
option, you end up having to make a wrapper for the specific format you
want to print. This means that, in the end, I am better off just writing
very long lines with @sprintf.

Anyway, I again apologize for my harsh tone, I hope I have clarified some
of my thoughts, I hope I have re-assured you that I did look at the
alternatives, and I thank you for your work in Julia.

Daniel.

Re: [julia-users] linspace and HDF5

[Steven G. Johnson]

On Monday, September 21, 2015 at 2:03:35 PM UTC-4, Tom Breloff wrote:
>
> This seemed to match:
>

Note that you don't need meshgrid for this example, and it is more 
efficient to avoid it.  You can use broadcasting, and pcolormesh will do 
the right thing if you pass it a row vector and column vector as the first 
two arguments:

using PyPlot, PyCall
@pyimport matplotlib.colors as COL
x = linspace(1, 20, 101)'
y = linspace(2, 5, 101)
data = x .+ y
plt = pcolormesh(x, y, data, norm = COL.LogNorm(vmin=minimum(data), 
vmax=maximum(data)))
colorbar()


I used to use meshgrid, but I haven't encountered a case where I actually 
need it, even with PyPlot. 

Re: [julia-users] Re: @sprintf with a format string

[lawrence dworsky]

Hi Tom

What I like about it is that you can just use print *, dumbly and it always
provides useful, albeit not beautiful, results. When I'm writing a program,
I use print statements very liberally to observe what's going on - I find
this more convenient than an in-line debugger.

As the last line in my program below shows, it's easy to switch to
formatted output when you want to. The formatting capability is pretty
thorough, I'm just showing a simple example.

This Fortran program doesn't do anything, it just illustrates what the
print statement produces:


real x, y
integer i, j
complex z
character*6  name

x = 2.6
y = -4.
i = 36
j = -40
z = cmplx(17., 19.)
name = 'Larry'

print *, x, y, i, j, z
print *, 'x = ', x, ' and j = ', j
print *, 'Hello, ', name, j
print '(2f8.3, i5)', x, y, j

stop
end


The output is:

2.6 -4.0   36 -40
 (17., 19.)
x = 2.6   and j =-40
Hello, Larry -40
  2.600   -4.000  -40


Is this what you are looking for?

Larry



On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff  wrote:

> Larry: can you provide details on exactly what you like about Fortran's
> print statement?  Did it provide good defaults?  Was it easy to customize?
>
> On Tue, Sep 22, 2015 at 12:55 PM, LarryD  wrote:
>
>> Something I miss from Fortran is the very convenient default "print *,
>> . "  It handled almost 100% of my needs while working on a program and
>> was easily replaced by real formatting when the time came. Is there any
>> chance that Julia could get something like this?
>>
>> Thanks
>>
>>
>> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti wrote:
>>>
>>> Dear all,
>>>
>>> I could use some help here, because I can't believe I'm not able to
>>> easily print formatted numbers under Julia in a easy way. What I try to do
>>> is to write a function that, given a vector, prints all its components with
>>> a user-defined format. I was trying something of the form
>>>
>>> function Print_Vec(aux_VEC,form_VEC)
>>> form_VEC :: ASCIIString
>>> str_VEC  = "%16.8f"
>>> for elem_VEC in aux_VEC
>>> str_VEC += @sprintf(form_VEC,elem_VEC)
>>> end
>>> return str_VEC
>>> end
>>>
>>> However, that doesn't work because it looks like the first argument in
>>> @sprintf must be a explicit string, and not a variable.
>>> Is there anything I can do with that?
>>>
>>> Thanks a lot for your help.
>>>
>>
>

Re: [julia-users] Re: @sprintf with a format string

[Stefan Karpinski]

Possible, but I don't relish the thought of forever explaining to people
that they need to use printf with or without the @ depending on if they
want it to be fast or flexible. If you really don't care about speed, you
can just do this right now:

printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
$(args...))


But actually don't do that because it's so horrifically slow and
inefficient I just can't.

On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  wrote:

>
> On 22 September 2015 at 20:40, Stefan Karpinski 
> wrote:
>
>> I think that before any further discussion takes place of how easy or
>> hard implementing a high-performance printf is, anyone who'd like to
>> comment should spend some time perusing GNU libc's vfprintf
>> implementation
>> .
>> This code is neither easy nor trivial – it's batsh*t crazy.
>>
>
> That is insane... 2388 lines, half of it macros, and I have no idea how it
> works.
>
>
>
>> And we want to match its performance yet be much more flexible and
>> generic. The current printf implementation does just that, while being
>> somewhat less insane GNU's printf code. If someone has bright ideas for how
>> to *also* allow runtime format specification without sacrificing
>> performance or generality, I'm all ears.
>>
>
>
> This might be a stupid question, but what's the harm in sacrificing
> performance as long as we keep the current @sprintf for scenarios that call
> for performance? I don't always need printf() to be fast.
>
>
>
>
>> I have some thoughts, but they're just that – thoughts. One option is to
>> change the design and avoid printf-style formatting altogether. But then
>> I'm sure I'll never hear the end of it with people kvetching about how we
>> don't have printf.
>>
>
> Probably. Everyone is used to printf and they are comfortable with it.
>
> Daniel.
>

Re: [julia-users] linspace and HDF5

[Jan Strube]

The julia example doesn't need meshgrid at all.


On Tuesday, September 22, 2015 at 2:37:55 AM UTC-7, Christoph Ortner wrote:
>
> another example why meshgrid should be in Base. :)
> Christoph
>

Re: [julia-users] Re: @sprintf with a format string

[Stefan Karpinski]

I think that before any further discussion takes place of how easy or hard
implementing a high-performance printf is, anyone who'd like to comment
should spend some time perusing GNU libc's vfprintf implementation
.
This code is neither easy nor trivial – it's batsh*t crazy. And we want to
match its performance yet be much more flexible and generic. The current
printf implementation does just that, while being somewhat less insane
GNU's printf code. If someone has bright ideas for how to *also* allow
runtime format specification without sacrificing performance or generality,
I'm all ears. I have some thoughts, but they're just that – thoughts. One
option is to change the design and avoid printf-style formatting
altogether. But then I'm sure I'll never hear the end of it with people
kvetching about how we don't have printf.

On Tue, Sep 22, 2015 at 1:22 PM, Daniel Carrera  wrote:

>
> On 22 September 2015 at 17:42, Stefan Karpinski 
> wrote:
>
>> Responding with a solicitation for help in an open source project is not
>> a rhetorical ploy – it's a legitimate request for contribution.
>>
>
> It can be either. It depends on context and intent. I have seen that
> comment used both ways. I once saw a seminar that suggested that as a
> technique to get rid of people you don't want to deal with (e.g. because
> the person is disruptive in some way).
>
>
> A lecture on the importance of printing numbers is also not helpful and
>> pretty irritating. Yes, printing things is important, especially numbers.
>> Everyone is well aware, myself included – that's why I spent a month
>> implementing our generic printf in the first place. It will get fixed.
>>
>
>
> I don't know if this is a response to me or someone else. I never gave a
> lecture on the importance of printing numbers. At least, I never intended
> to and I don't know what I said that would come across like that.
>
> Anyway, I appreciate that you are busy with probably more important
> things, and I thank you for the work you have already done. My email was
> harsher than it should have been, but I was replying comments from Tomas. I
> was not trying to file a complaint with the Julia devs. I know that you
> know about the @sprintf() issue, and I was not trying to remind you of it.
> I took issue with Tomas saying that printf() was not implemented because
> the devs were trying to decide what the right implementation should be. I
> don't think that this is, or should be, the right reason to not implement
> printf(). I suspected that the real reason was, as you said, that there is
> more work on your planet than just printf().
>
>
>
>
>> In the mean time, several viable solutions have been provided
>> (repeatedly), including...
>>
>
> I was not aware of the eval() option, but I was aware of the others. In
> particular, I spent a while experimenting with C's printf() function, but I
> was not able to make a generic wrapper around it. This means that, for me,
> a direct call to C's printf is no more useful than the existing @sprintf
> macro. I also compared Formatter.jl with @sprintf and I decided that
> @sprintf served me better.
>
>
>
>> 2. *Use Formatting.jl.* If you don't care for the interface, help
>> improve it. Help could take the form of pull requests, of just polite
>> issues opened to suggest how the interface could be enhanced. Calling it 
>> "next
>> to useless" and dismissing out of hand is rude and not particularly
>> constructive.
>>
>
> I was rude and I apologize. I don't think that Formatting.jl can be fixed.
> I think that there is probably a good reason it only provides sprintf1(). I
> don't think it would be news to the developers that a sprintf() that takes
> more than one parameter is desirable. If they haven't done it, it is
> because they can't.
>
>
>
>> 3. *Use C's printf.* Since this seems to be what you want and you can
>> easily call C from Julia, what's stopping you?
>>
>> julia> ccall(:printf, Cint,
>>  (Cstring, Cint, Cstring, Cdouble),
>>  "%05d %-5s %5.2f\n", 123, "flux", pi)
>> 00123 flux   3.14
>> 18
>>
>>
>> It's not the most convenient interface in the world, but a little
>> wrapping would solve that. (It may also be incorrect since printf is a
>> varargs function – I was a little surprised that it worked – but using
>> vprintf would address that.)
>>
>
> Yes, this is the approach I tried to work on. I was trying to make a
> wrapper. But I was unable to make a generic one. Similar to the @eval
> option, you end up having to make a wrapper for the specific format you
> want to print. This means that, in the end, I am better off just writing
> very long lines with @sprintf.
>
> Anyway, I again apologize for my harsh tone, I hope I have clarified some
> of my thoughts, I hope I have re-assured you that I did look at the
> alternatives, and I thank you for your 

[julia-users] Re: What's your favourite editor?

[Andrei Zh]

And here's all the code from my init.el related to development in Julia

;; auto-complete   
(ac-
config-default)

;; ido 
(ido-
mode)

;; Julia   
   
(load "~/.emacs.d/ESS/lisp/ess-site")
(setq inferior-julia-program-name "julia")
(add-hook 'julia-mode-hook
  '(lambda ()
 (local-set-key (kbd "C-d")
'ess-eval-line-and-step)
 (local-set-key (kbd "C-c C-c") 'ess-load-file)))
(setq ess-use-auto-complete t)
(setq ess-tab-complete-in-script t)




On Tuesday, September 22, 2015 at 4:16:33 PM UTC+3, Andrei Zh wrote:
>
>
>
>> I'd be grateful to hear from other emacs users regarding your workflows 
>> for Julia development, e.g. if you want to write a Julia package what emacs 
>> packages, setup and workflow help you to be the most productive?
>>
>>
> I use ESS + autocomplete + few keybindings (I'll post exact .init.el later 
> when I get home), but there's one important thing about code organization 
> that I worked out with time and now find very convenient. 
>
> When developing a module, I put all the code in a file called "core.jl" 
>  (or other files included into "core.jl"), and then in "MyModule.jl" simply 
> write:
>
> module MyModule
> export ...
>
>
> include("core.jl")
>
>
> end
>
>
>
> This allows to open "core.jl" in Emacs, load the file (C-c C-c) and work 
> like "from inside" the module, i.e. reload any function, keep variables, 
> types, etc. without the need to reload the whole module and thus reset all 
> variables. 
>

Re: [julia-users] Re: @sprintf with a format string

[Tom Breloff]

Thanks Larry, that's helpful.  Just for discussions sake, here's a quick 
macro that calls my proposed `fmt` method under the hood, and does 
something similar to what you showed.  What do you think about this style 
(and what would you do differently)?
 
using Formatting

macro fmt(args...)
 expr = Expr(:block)
 expr.args = [:(print(fmt($(esc(arg))), "\t\t")) for arg in args]
 push!(expr.args, :(println()))
 expr
end


And then an example usage:

In:

x = 1010101
y = 55.5
fmt_default!(width=15)

@fmt x y

fmt_default!(Int, :commas)
fmt_default!(Float64, prec=2)

@fmt x y


Out:

1010101  55.56 
  1,010,101  55.56



On Tuesday, September 22, 2015 at 3:08:35 PM UTC-4, lawrence dworsky wrote:
>
> Hi Tom
>
> What I like about it is that you can just use print *, dumbly and it 
> always provides useful, albeit not beautiful, results. When I'm writing a 
> program, I use print statements very liberally to observe what's going on - 
> I find this more convenient than an in-line debugger. 
>
> As the last line in my program below shows, it's easy to switch to 
> formatted output when you want to. The formatting capability is pretty 
> thorough, I'm just showing a simple example.
>
> This Fortran program doesn't do anything, it just illustrates what the 
> print statement produces:
>
>
> real x, y
> integer i, j
> complex z
> character*6  name
>
> x = 2.6
> y = -4.
> i = 36
> j = -40
> z = cmplx(17., 19.)
> name = 'Larry'
>
> print *, x, y, i, j, z
> print *, 'x = ', x, ' and j = ', j
> print *, 'Hello, ', name, j
> print '(2f8.3, i5)', x, y, j
>
> stop
> end
>
>
> The output is:
>
> 2.6 -4.0   36 -40 
>  (17., 19.)
> x = 2.6   and j =-40
> Hello, Larry -40
>   2.600   -4.000  -40
>
>
> Is this what you are looking for?
>
> Larry
>
>
>
> On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff  > wrote:
>
>> Larry: can you provide details on exactly what you like about Fortran's 
>> print statement?  Did it provide good defaults?  Was it easy to customize?
>>
>> On Tue, Sep 22, 2015 at 12:55 PM, LarryD > > wrote:
>>
>>> Something I miss from Fortran is the very convenient default "print *, 
>>> . "  It handled almost 100% of my needs while working on a program and 
>>> was easily replaced by real formatting when the time came. Is there any 
>>> chance that Julia could get something like this?
>>>
>>> Thanks
>>>
>>>
>>> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti wrote:

 Dear all,

 I could use some help here, because I can't believe I'm not able to 
 easily print formatted numbers under Julia in a easy way. What I try to do 
 is to write a function that, given a vector, prints all its components 
 with 
 a user-defined format. I was trying something of the form

 function Print_Vec(aux_VEC,form_VEC)
 form_VEC :: ASCIIString
 str_VEC  = "%16.8f"
 for elem_VEC in aux_VEC
 str_VEC += @sprintf(form_VEC,elem_VEC)
 end
 return str_VEC
 end

 However, that doesn't work because it looks like the first argument in 
 @sprintf must be a explicit string, and not a variable.
 Is there anything I can do with that?

 Thanks a lot for your help.

>>>
>>
>

[julia-users] Tripping myself up on macro hygiene (again...)

[Tomas Lycken]

I’m having real difficulties grok-ing macro hygiene. I’ve read the manual 
entry, but didn’t get much wiser, so I’m hoping the solution to my current 
problem will be another data point I can use to understand (and I need this 
to work :P).

I have a utility function that builds an expression (which will later be 
interpolated into the method body of a generated function, but that’s out 
of scope for my current problem), something like this:

julia> using Base.Cartesian

julia> foo(N) = :(gradient(A, (@ntuple $N k->xs_k)...))
foo (generic function with 1 method)

julia> macroexpand(foo(2))
:(gradient(A,(xs_1,xs_2)...))

Now, as you see, the generated tuple is splatted at run time. I’d like to 
try to move that splatting to compile time, so that the generated 
expression is rather :(gradient(A, xs_1, xs_2)). I’ve tried variants on the 
following, but as you can see I haven’t had any success.

I assume that I need to escape N somehow - but how?

julia> foo(N) = :(gradient(A, $((@ntuple N k->xs_k)...)))
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, ::Expr)

julia> foo(N) = :(gradient(A, $((@ntuple $N k->xs_k)...)))
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)

julia> foo(N) = :(gradient(A, $(esc((@ntuple N k->xs_k)...
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, ::Expr)

julia> foo(N) = :(gradient(A, $(esc((@ntuple :N k->xs_k)...
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)

julia> foo(N) = :(gradient(A, $(@ntuple esc(N) k->xs_k)...))
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)

julia> foo(N) = :(gradient(A, $(@ntuple esc(:N) k->xs_k)...))
ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)

​

Re: [julia-users] Re: @sprintf with a format string

[Tom Breloff]

Larry: can you provide details on exactly what you like about Fortran's
print statement?  Did it provide good defaults?  Was it easy to customize?

On Tue, Sep 22, 2015 at 12:55 PM, LarryD  wrote:

> Something I miss from Fortran is the very convenient default "print *,
> . "  It handled almost 100% of my needs while working on a program and
> was easily replaced by real formatting when the time came. Is there any
> chance that Julia could get something like this?
>
> Thanks
>
>
> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti wrote:
>>
>> Dear all,
>>
>> I could use some help here, because I can't believe I'm not able to
>> easily print formatted numbers under Julia in a easy way. What I try to do
>> is to write a function that, given a vector, prints all its components with
>> a user-defined format. I was trying something of the form
>>
>> function Print_Vec(aux_VEC,form_VEC)
>> form_VEC :: ASCIIString
>> str_VEC  = "%16.8f"
>> for elem_VEC in aux_VEC
>> str_VEC += @sprintf(form_VEC,elem_VEC)
>> end
>> return str_VEC
>> end
>>
>> However, that doesn't work because it looks like the first argument in
>> @sprintf must be a explicit string, and not a variable.
>> Is there anything I can do with that?
>>
>> Thanks a lot for your help.
>>
>

[julia-users] Re: Juno stopped working - error message

[Haoran Jiang]

Hi Greg, I am new to Julia and Juno, I just installed this software today 
and I have the same error message as you do, can you tell me what did you 
do to make it right? this is my Pkg.status. I never had it worked 
before(since it is my first day install it) so i dont know what file to 
change and where to change them, Thanks!


在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
>
> Serge,
>
> Below is output of Pkg.status():
>
> I had previously tried removing many packages, but nothing is pinned (so 
> not sure if rolling back will result in same config)
>
> The only error message I receive using Juno is:
> symbol could not be found jl_generating_output (-1): The specified 
> procedure could not be found.
>
> but after this everything seems to work as normal.
>
> Hope this helps.
> -- Greg
>
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
> julia> Pkg.status()
> 9 required packages:
>  - Dates 0.3.2
>  - Distributions 0.8.6
>  - HDF5  0.5.5
>  - ImageView 0.1.16
>  - Images0.4.47
>  - JLD   0.5.4
>  - Jewel 1.0.6
>  - Optim 0.4.2
>  - ZMQ   0.2.0
> 39 additional packages:
>  - ArrayViews0.6.3
>  - BinDeps   0.3.15
>  - Blosc 0.1.4
>  - Cairo 0.2.30
>  - Calculus  0.1.10
>  - ColorTypes0.1.4
>  - ColorVectorSpace  0.0.3
>  - Colors0.5.3
>  - Compat0.7.1
>  - Compose   0.3.15
>  - DataStructures0.3.12
>  - Docile0.5.18
>  - DualNumbers   0.1.3
>  - FactCheck 0.4.0
>  - FixedPointNumbers 0.0.10
>  - Graphics  0.1.0
>  - HttpCommon0.1.2
>  - IniFile   0.2.4
>  - Iterators 0.1.8
>  - JSON  0.4.5
>  - JuliaParser   0.6.2
>  - LNR   0.0.1
>  - Lazy  0.10.0
>  - LibExpat  0.0.8
>  - MacroTools0.2.0
>  - NaNMath   0.1.0
>  - PDMats0.3.5
>  - Reexport  0.0.3
>  - Requires  0.2.0
>  - SHA   0.1.1
>  - SIUnits   0.0.5
>  - StatsBase 0.7.2
>  - StatsFuns 0.1.3
>  - TexExtensions 0.0.2
>  - Tk0.3.6
>  - URIParser 0.0.7
>  - WinRPM0.1.12
>  - Winston   0.11.12
>  - Zlib  0.1.9
> Julia>
>
>
>
> On Monday, September 21, 2015 at 9:44:24 AM UTC+10, Serge Santos wrote:
>
> Hi All,
>
> I tried to roll back to JuliaParser v0.6.2 and it didn't work. 
>
> If someone still manages to successfully run Juno with Julia 0.3.11, can 
> you please send the list of packages with version numbers that does not 
> create any issues with Juno (i.e,, output from Pkg.status()). I was not 
> able to figure out what combination of versions work. 
>
> Many thanks in advance
> Serge
>
> On Monday, 21 September 2015 00:16:27 UTC+1, Greg Plowman wrote:
>
> Hi All,
>
> On 2 different PCs where Juno works (almost without error) Pkg.status() 
> reports JuliaParser v0.6.2
> On PC that has Juno errors, Pkg.status() reports JuliaParser v0.6.3
> Rolling back to JuliaParser v0.1.2 creates different errors.
> So it seems we need to revert to JuliaParser v0.6.2
>
> I'm not at a PC where I can see if we can pin v0.6.2, in light of the 
> following:
>
> Before this JuliaParser was at version v0.6.3, are you sure we should try 
> reverting to v0.1.2?
>
> See the tagged versions 
>
> https://github.com/jakebolewski/JuliaParser.jl/releases. So that’s the 
> next latest tagged version. You could probably checkout a specific commit 
> prior to the commit that’s causing the breakage instead though.
>
> Also, I don't want to play around with Pkg.ANYTHING on a working 
> configuration at the moment :)
>
> -- Greg
>
>
> On Monday, September 21, 2015 at 4:50:37 AM UTC+10, Tony Kelman wrote:
>
> What's temporarily broken here is some of the packages that 
> Light-Table-based Juno relies on to work. In the meantime you can still use 
> command-line REPL Julia, and while it's not the most friendly interface 
> your 

Re: [julia-users] Re: Juno stopped working - error message

[Spencer Russell]

Hi Haoran,

Try pinning the Compat package by running `Pkg.pin("Compat", v"0.7.0")`

If you're running Julia 0.3.11 that should be the newest version that
will install, so I'm not sure how you ended up with Compat 0.7.3 (which
is currently tagged to be 0.4 and newer). That's a pretty recent change
though(yesterday evening), but if you just installed today I'd think
you'd be good to go.

-s


On Tue, Sep 22, 2015, at 02:58 AM, Haoran Jiang wrote:
> Hi Greg, I am new to Julia and Juno, I just installed this software
> today and I have the same error message as you do, can you tell me
> what did you do to make it right? this is my Pkg.status. I never had
> it worked before(since it is my first day install it) so i dont know
> what file to change and where to change them, Thanks!
>
>
> 在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
>> Serge,
>>
>> Below is output of Pkg.status():
>>
>> I had previously tried removing many packages, but nothing is pinned
>> (so not sure if rolling back will result in same config)
>>
>> The only error message I receive using Juno is:    symbol could not
>> be found jl_generating_output (-1): The specified procedure could not
>> be found.
>>
>> but after this everything seems to work as normal.
>>
>> Hope this helps. -- Greg
>>
>>
>>
>> _   _   _ _(_)_ |  A fresh approach to technical computing
>> (_) | (_) (_)    |  Documentation: http://docs.julialang.org   _
>> _   _| |_  __ _   |  Type "help()" for help.  | | | | | | |/ _` |  |
>> | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC) _/
>> |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
>> |__/   |  x86_64-w64-mingw32
>> julia> Pkg.status()
>> 9 required packages: - Dates 0.3.2 -
>> Distributions 0.8.6 - HDF5
>> 0.5.5 - ImageView 0.1.16 - Images
>> 0.4.47 - JLD   0.5.4 - Jewel
>> 1.0.6 - Optim 0.4.2 - ZMQ
>> 0.2.0 39 additional packages: - ArrayViews
>> 0.6.3 - BinDeps   0.3.15 - Blosc
>> 0.1.4 - Cairo 0.2.30 - Calculus
>> 0.1.10 - ColorTypes    0.1.4 -
>> ColorVectorSpace  0.0.3 - Colors
>> 0.5.3 - Compat    0.7.1 - Compose
>> 0.3.15 - DataStructures    0.3.12 - Docile
>> 0.5.18 - DualNumbers   0.1.3 - FactCheck
>> 0.4.0 - FixedPointNumbers 0.0.10 - Graphics
>> 0.1.0 - HttpCommon    0.1.2 - IniFile
>> 0.2.4 - Iterators 0.1.8 - JSON
>> 0.4.5 - JuliaParser   0.6.2 - LNR
>> 0.0.1 - Lazy  0.10.0 - LibExpat
>> 0.0.8 - MacroTools    0.2.0 - NaNMath
>> 0.1.0 - PDMats    0.3.5 - Reexport
>> 0.0.3 - Requires  0.2.0 - SHA
>> 0.1.1 - SIUnits   0.0.5 - StatsBase
>> 0.7.2 - StatsFuns 0.1.3 - TexExtensions
>> 0.0.2 - Tk    0.3.6 - URIParser
>> 0.0.7 - WinRPM    0.1.12 - Winston
>> 0.11.12 - Zlib  0.1.9
>> Julia>
>>
>>
>>
>>
>> On Monday, September 21, 2015 at 9:44:24 AM UTC+10, Serge
>> Santos wrote:
>>> Hi All,
>>>
>>> I tried to roll back to JuliaParser v0.6.2 and it didn't work.
>>>
>>> If someone still manages to successfully run Juno with Julia 0.3.11,
>>> can you please send the list of packages with version numbers that
>>> does not create any issues with Juno (i.e,, output from
>>> Pkg.status()). I was not able to figure out what combination of
>>> versions work.
>>>
>>> Many thanks in advance Serge
>>>
>>> On Monday, 21 September 2015 00:16:27 UTC+1, Greg Plowman  wrote:
 Hi All,

 On 2 different PCs where Juno works (almost without error)
 Pkg.status() reports JuliaParser v0.6.2 On PC that has Juno errors,
 Pkg.status() reports JuliaParser v0.6.3 Rolling back to JuliaParser
 v0.1.2 creates different errors. So it seems we need to revert to
 JuliaParser v0.6.2

 I'm not at a PC where I can see if we can pin v0.6.2, in light of
 the following:



>> Before this JuliaParser was at version v0.6.3, are you sure we
>> should try reverting to v0.1.2?






> See the tagged versions
> https://github.com/jakebolewski/JuliaParser.jl/releases. So that’s
> the next latest tagged version. You could probably checkout a
> specific commit prior to the commit that’s causing the breakage
> instead though.









 Also, I don't want to play around with Pkg.ANYTHING on a working
 configuration at the moment :)



 -- Greg


 On Monday, September 21, 2015 at 4:50:37 AM UTC+10, Tony Kelman
 wrote:
> What's temporarily broken here is some of the packages that Light-Table-
> based Juno relies on to work. In the meantime you can still use
> command-line REPL Julia, and while it's not the most 

Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

On 22 September 2015 at 16:38, Tomas Lycken  wrote:

> If anything I wrote came off as a "thinly veiled 'fuck you'", I am
> sincerely sorry; that's nowhere near what I meant to say.
>

Thank you. I guess I misinterpreted your comments and reacted more harshly
than I should.


Then, you replied that "Formatting.jl looks next to useless" and "I really
> don't understand why sprintf is such a big deal. If C can have one, why
> can't Julia?" I interpreted that, apparently wrongfully, as implying not
> only that you disliked the currently available implementations, but also
> that you thought it couldn't be so hard to do better, so my second answer
> had a different solution to the problem. (Note also that the two posts
> aren't directed at the same person.)
>


Well, I apologize if I made it sound that printf() was easy to write. You
have to admit that most languages provide printf() out of the box, so it
does seem odd that Julia does not.



> Re-reading the thread I think both our tones are harsher than necessary,
> and I apologize for my part in that.
>

I apologize as well. Both of my emails were harsher than they should have
been.

Daniel.

[julia-users] Re: @sprintf with a format string

[LarryD]

Something I miss from Fortran is the very convenient default "print *, 
. "  It handled almost 100% of my needs while working on a program and 
was easily replaced by real formatting when the time came. Is there any 
chance that Julia could get something like this?

Thanks

On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti wrote:
>
> Dear all,
>
> I could use some help here, because I can't believe I'm not able to easily 
> print formatted numbers under Julia in a easy way. What I try to do is to 
> write a function that, given a vector, prints all its components with a 
> user-defined format. I was trying something of the form
>
> function Print_Vec(aux_VEC,form_VEC)
> form_VEC :: ASCIIString
> str_VEC  = "%16.8f"
> for elem_VEC in aux_VEC
> str_VEC += @sprintf(form_VEC,elem_VEC)
> end
> return str_VEC
> end
>
> However, that doesn't work because it looks like the first argument in 
> @sprintf must be a explicit string, and not a variable.
> Is there anything I can do with that?
>
> Thanks a lot for your help.
>

[julia-users] Re: FFTW.REDFT00 and FFT.RODFT00 are ~10x slower than other routines?

[Steven G. Johnson]

On Tuesday, September 22, 2015 at 6:51:50 AM UTC-4, Sheehan Olver wrote:
>
> I get the following timings with the various FFTW routines, where I ran 
> each line multiple times to make sure it was accurate.  Why are REDFT00 and 
> RODFT00 almost 10x slower?
>

This is because a REDFT00 (DCT-I) of n points is exactly equivalent to a 
DFT of N=2(n-1) points with real-even data.  Although FFTW uses a different 
algorithm, not a size-N complex FFT, the fast algorithms are essentially 
equivalent to pruned versions of the FFT algorithms for N, and depend on 
the factorization of N, not of n.  Similarly for RODFT00 (DST-I), except 
N=2(n+1) in that case.  In contrast, the other DCT/DST types correspond to 
DFTs of length N=2n or N=4n or N=8n, so their speed depends on the 
factorization of n.

If n=10 as in your example, then n-1 has large prime factors (41, 271), 
so the FFT algorithms are much slower, although they are still O(n log n). 
  If you try n=11, you will notice that REDFT00 becomes much faster 
(but other DCT types become slower).

This is mentioned in the FFTW manual:

http://www.fftw.org/doc/Real-even_002fodd-DFTs-_0028cosine_002fsine-transforms_0029.html

"FFTW is most efficient when N is a product of small factors; note that 
this *differs* from the factorization of the physical size n for REDFT00 
and RODFT00!"

Re: [julia-users] Re: @sprintf with a format string

[Stefan Karpinski]

It also allocates 1MB just to print three numbers. Yikes.

On Tue, Sep 22, 2015 at 4:34 PM, Daniel Carrera  wrote:

> Hmm... I know it's horrible, but I just added that to my juliarc file :-)
>
> This function is 100x slower than the macro, at about 100 lines in 0.5s. I
> know that's horribly slow for traditional printf() but it's fast enough for
> terminal output.
>
>
>
> On 22 September 2015 at 22:06, Stefan Karpinski 
> wrote:
>
>> Possible, but I don't relish the thought of forever explaining to people
>> that they need to use printf with or without the @ depending on if they
>> want it to be fast or flexible. If you really don't care about speed, you
>> can just do this right now:
>>
>> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
>> $(args...))
>>
>>
>> But actually don't do that because it's so horrifically slow and
>> inefficient I just can't.
>>
>> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera 
>> wrote:
>>
>>>
>>> On 22 September 2015 at 20:40, Stefan Karpinski 
>>> wrote:
>>>
 I think that before any further discussion takes place of how easy or
 hard implementing a high-performance printf is, anyone who'd like to
 comment should spend some time perusing GNU libc's vfprintf
 implementation
 .
 This code is neither easy nor trivial – it's batsh*t crazy.

>>>
>>> That is insane... 2388 lines, half of it macros, and I have no idea how
>>> it works.
>>>
>>>
>>>
 And we want to match its performance yet be much more flexible and
 generic. The current printf implementation does just that, while being
 somewhat less insane GNU's printf code. If someone has bright ideas for how
 to *also* allow runtime format specification without sacrificing
 performance or generality, I'm all ears.

>>>
>>>
>>> This might be a stupid question, but what's the harm in sacrificing
>>> performance as long as we keep the current @sprintf for scenarios that call
>>> for performance? I don't always need printf() to be fast.
>>>
>>>
>>>
>>>
 I have some thoughts, but they're just that – thoughts. One option is
 to change the design and avoid printf-style formatting altogether. But then
 I'm sure I'll never hear the end of it with people kvetching about how we
 don't have printf.

>>>
>>> Probably. Everyone is used to printf and they are comfortable with it.
>>>
>>> Daniel.
>>>
>>
>>
>

Re: [julia-users] Re: @sprintf with a format string

[Bob Nnamtrop]

But Michael Hatherly's showed code above that uses a generated function to
solve this. It seems to work pretty well in the short while I tried it in
the REPL. Granted I didn't time it or do anything complicated. It works on
Stefan's example above with no problem. The only difference is that one
must type fmt("format") instead of "format". Possibly that could be
shortened to fmt"format" using a str_macro (although that had some effects
when I tried it).

What am I missing?

Bob

On Tue, Sep 22, 2015 at 6:32 PM, Tom Breloff  wrote:

> I think not Luke.  Generated functions work on the types of the
> arguments.  If someone wants to format based on an input string, then you
> either need a hardcoded value which can go into a macro, or a dynamic value
> that would go in a normal function.
>
> If all you want to do is print out some arbitrary list of objects with
> pre-defined format, then a normal function should be plenty fast (and if
> it's a fixed format string, the current macro is the way to go).
>
> On Tue, Sep 22, 2015 at 8:21 PM, Luke Stagner 
> wrote:
>
>> Would it be possible to rewrite @printf as a generated function instead
>> of a macro. That way the calling syntax would be more familiar.
>>
>> On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski
>> wrote:
>>>
>>> Possible, but I don't relish the thought of forever explaining to people
>>> that they need to use printf with or without the @ depending on if they
>>> want it to be fast or flexible. If you really don't care about speed, you
>>> can just do this right now:
>>>
>>> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
>>> $(args...))
>>>
>>>
>>> But actually don't do that because it's so horrifically slow and
>>> inefficient I just can't.
>>>
>>> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera 
>>> wrote:
>>>

 On 22 September 2015 at 20:40, Stefan Karpinski 
 wrote:

> I think that before any further discussion takes place of how easy or
> hard implementing a high-performance printf is, anyone who'd like to
> comment should spend some time perusing GNU libc's vfprintf
> implementation
> .
> This code is neither easy nor trivial – it's batsh*t crazy.
>

 That is insane... 2388 lines, half of it macros, and I have no idea how
 it works.



> And we want to match its performance yet be much more flexible and
> generic. The current printf implementation does just that, while being
> somewhat less insane GNU's printf code. If someone has bright ideas for 
> how
> to *also* allow runtime format specification without sacrificing
> performance or generality, I'm all ears.
>


 This might be a stupid question, but what's the harm in sacrificing
 performance as long as we keep the current @sprintf for scenarios that call
 for performance? I don't always need printf() to be fast.




> I have some thoughts, but they're just that – thoughts. One option is
> to change the design and avoid printf-style formatting altogether. But 
> then
> I'm sure I'll never hear the end of it with people kvetching about how we
> don't have printf.
>

 Probably. Everyone is used to printf and they are comfortable with it.

 Daniel.

>>>
>>>
>

[julia-users] Re: When does colon indexing get evaluated / converted?

['Greg Plowman' via julia-users]

Matt,
Thankyou so much for your great reply.
And yes it does make sense now after such a helpful and well-targeted 
explanation.
You explained "colon-lowering" in a "explanation-lowered" way that a 
non-expert can understand.
This is refreshingly thoughtful and helpful.
Thanks again.
-- Greg

 
On Tuesday, September 22, 2015 at 11:09:41 PM UTC+10, Matt Bauman wrote:

> A colon by itself is simply a synonym for `Colon()`, both on 0.3 and 0.4:
>  
> julia> :
> Colon()
>  
> You can use colons in normal function calls and dispatch in both 0.3 and 
> 0.4:
>  
> julia> f(x::Colon) = x
>f(:)
> Colon()
>  
> That's what's happening with that sub definition.  `sub` acts like 
> indexing, but it's just a normal function call.  And so the Colon() passes 
> through unchanged in both 0.3 and 0.4.
>  
> Indexing expressions are different.  There are some special lowering steps 
> to handle colon (just in 0.3) and end (in both 0.3 and 0.4).  "Lowering" is 
> an intermediate step between parsing and compilation, and you can see what 
> happens to an expression during lowering by calling `expand`.  The expanded 
> expressions have some funny things in them (`top(endof)(A)` is a special 
> internal pseudo-syntax that is kinda-sorta like saying `Base.endof(A)`), 
> but you can see how the `end` keyword lowers to getindex calls in both 0.3 
> and 0.4:
>  
> julia> expand(:(A[end]))
> :(getindex(A,(top(endof))(A)))
>  
> julia> expand(:(A[1, end]))
> :(getindex(A,1,(top(trailingsize))(A,2)))
>  
> julia> expand(:(A[1, end, 3]))
> :(getindex(A,1,(top(size))(A,2),3))
>  
> So, now to the difference between 0.3 and 0.4: the special lowering step 
> for colons in indexing expressions was removed.
>  
> # Julia 0.3:
> julia> expand(:(A[:]))
> :(getindex(A,colon(1,(top(endof))(A
>  
> # Julia 0.4:
> julia> expand(:(A[:]))
> :(getindex(A,:))
>  
> You can see that in 0.3, it effectively expanded to `1:end`.  But 0.4 just 
> left the `:` symbol as it was, and it just gets evaluated normally as an 
> argument to getindex.  It's no longer special. So in 0.4, you can 
> specialize dispatch on Colon indices.
>  
> Make sense?
>  
> On Tuesday, September 22, 2015 at 1:07:01 AM UTC-4, Greg Plowman wrote:
>>
>> Hi All,
>> Thanks all for your replies.
>>  
>> OK I can see this will be much easier in v0.4.
>> I will revisit when v0.4 released.
>>  
>> I'm still curious about colon and end
>>
>>> Colon lowering changed in 0.4, 
>>
>>  
>> Matt, could you expand on this? How/when is this done in v0.3 vs v0.4?
>>  
>> Does this mean v0.3 code attempting to dispatch on Colon type cannot 
>> work? (for example the code from subarray.jl quoted below) 
>>  
>> sub(A::AbstractArray, I::Union(RangeIndex, Colon)...) = sub(A, ntuple(
>> length(I), i-> isa(I[i], Colon) ? (1:size(A,i)) : I[i])...)
>>  
>> I noticed that  OffsetArrays (https://github.com/alsam/OffsetArrays.jl 
>> 
>>  
>> jA 
>> )
>>  
>> defines const (..) = Colon(), presumably to use .. in place of :
>>  
>> Will it work in v0.4?
>> How and when is end converted?
>>  
>> Thanks again,
>> Greg
>>  
>>  
>>  
>>
>

Re: [julia-users] Re: @sprintf with a format string

[Tim Holy]

On Tuesday, September 22, 2015 05:21:10 PM Luke Stagner wrote:
> Would it be possible to rewrite @printf as a generated function instead of
> a macro. That way the calling syntax would be more familiar.

That's a good suggestion.

At the risk of encouraging emacs users to "fix" the syntax with ctrl-T, I'd 
propose the following (apparently complete?) solution:


immutable FormatString{S} end

FormatString(str::AbstractString) = FormatString{symbol(str)}

macro f_str(arg)
:(FormatString{symbol($arg)})
end

@generated function Base.print{format}(::Type{FormatString{format}}, args...)
meta = Expr(:meta, :inline)
fmt = string(format)
allargs = [:(args[$d]) for d = 1:length(args)]
quote
@printf($fmt, $(allargs...))
end
end



Demo:
julia> print(f"%.3f", pi)
3.142
julia> function foo(strs)
   for str in strs
   print(FormatString(str), pi)
   end
   end
foo (generic function with 1 method)

julia> strs = ("%.3f\n", "%.5f\n")
("%.3f\n","%.5f\n")

julia> foo(strs)
3.142
3.14159

julia> @time 1   # just to warm up @time
  0.04 seconds (148 allocations: 10.151 KB)
1

julia> @time foo(strs)
3.142
3.14159
  0.000106 seconds (18 allocations: 704 bytes)


Nice that we get to re-use the macro that Stefan worked so hard on!

Best,
--Tim

> 
> On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski wrote:
> > Possible, but I don't relish the thought of forever explaining to people
> > that they need to use printf with or without the @ depending on if they
> > want it to be fast or flexible. If you really don't care about speed, you
> > can just do this right now:
> > 
> > printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
> > $(args...))
> > 
> > 
> > But actually don't do that because it's so horrifically slow and
> > inefficient I just can't.
> > 
> > On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  > 
> > > wrote:
> >> On 22 September 2015 at 20:40, Stefan Karpinski  >> 
> >> > wrote:
> >>> I think that before any further discussion takes place of how easy or
> >>> hard implementing a high-performance printf is, anyone who'd like to
> >>> comment should spend some time perusing GNU libc's vfprintf
> >>> implementation
> >>>  >>> cc63:/stdio-common/vfprintf.c>. This code is neither easy nor trivial –
> >>> it's batsh*t crazy.
> >> 
> >> That is insane... 2388 lines, half of it macros, and I have no idea how
> >> it works.
> >> 
> >>> And we want to match its performance yet be much more flexible and
> >>> generic. The current printf implementation does just that, while being
> >>> somewhat less insane GNU's printf code. If someone has bright ideas for
> >>> how
> >>> to *also* allow runtime format specification without sacrificing
> >>> performance or generality, I'm all ears.
> >> 
> >> This might be a stupid question, but what's the harm in sacrificing
> >> performance as long as we keep the current @sprintf for scenarios that
> >> call
> >> for performance? I don't always need printf() to be fast.
> >> 
> >>> I have some thoughts, but they're just that – thoughts. One option is to
> >>> change the design and avoid printf-style formatting altogether. But then
> >>> I'm sure I'll never hear the end of it with people kvetching about how
> >>> we
> >>> don't have printf.
> >> 
> >> Probably. Everyone is used to printf and they are comfortable with it.
> >> 
> >> Daniel.

[julia-users] Re: suppress deprecation warnings

[Tony Kelman]

Sorry about that, my bad for not testing before replying. It appears the 
recently added binding deprecations don't yet respect the --depwarn flag 
but that should be fixed soon 
with https://github.com/JuliaLang/julia/pull/13269 which should get 
backported to RC3.


On Thursday, September 17, 2015 at 11:03:15 AM UTC-7, Tony Kelman wrote:
>
> start julia with --depwarn=no
>
> On Thursday, September 17, 2015 at 10:28:10 AM UTC-7, Michael Francis 
> wrote:
>>
>> How can I suppress the printing of deprecation warnings in 0.4? I need to 
>> temporarily suppress these so that I can see the wood for the trees. 
>>
>

Re: [julia-users] Re: @sprintf with a format string

[Eric Forgy]

If this were Facebook, I would "Like" this :)

On Wednesday, September 23, 2015 at 9:34:27 AM UTC+8, Tim Holy wrote:
>
> At the risk of encouraging emacs users to "fix" the syntax with ctrl-T, 
> I'd 
> propose the following (apparently complete?) solution: 
>
>
> immutable FormatString{S} end 
>
> FormatString(str::AbstractString) = FormatString{symbol(str)} 
>
> macro f_str(arg) 
> :(FormatString{symbol($arg)}) 
> end 
>
> @generated function Base.print{format}(::Type{FormatString{format}}, 
> args...) 
> meta = Expr(:meta, :inline) 
> fmt = string(format) 
> allargs = [:(args[$d]) for d = 1:length(args)] 
> quote 
> @printf($fmt, $(allargs...)) 
> end 
> end 
>
>
>
> Demo: 
> julia> print(f"%.3f", pi) 
> 3.142 
> julia> function foo(strs) 
>for str in strs 
>print(FormatString(str), pi) 
>end 
>end 
> foo (generic function with 1 method) 
>
> julia> strs = ("%.3f\n", "%.5f\n") 
> ("%.3f\n","%.5f\n") 
>
> julia> foo(strs) 
> 3.142 
> 3.14159 
>
> julia> @time 1   # just to warm up @time 
>   0.04 seconds (148 allocations: 10.151 KB) 
> 1 
>
> julia> @time foo(strs) 
> 3.142 
> 3.14159 
>   0.000106 seconds (18 allocations: 704 bytes) 
>
>
> Nice that we get to re-use the macro that Stefan worked so hard on! 
>
> Best, 
> --Tim 
>

Re: [julia-users] Deprecation of require

[Steven G. Johnson]

On Friday, July 31, 2015 at 7:30:44 AM UTC-4, Tim Holy wrote:
>
> If MyModule.jl is on your LOAD_PATH, 
>
> @everywhere import MyModule 


Actually, the right thing is just:

import MyModule


That will import it on all workers (@everywhere is redundant), and is 
actually better than @everywhere because if the module needs to be 
re-precompiled then it will be compiled only once. 

[julia-users] [ANN] Julia v0.4.0-rc2 released

[Elliot Saba]

The second release candidate of the 0.4 series is available for download
from the usual place .  Please test
extensively, report issues to the issue tracker
 for base Julia problems, and
report issues with packages to their respective issue trackers.  The 0.4
series will undergo a period of stabilization in anticipation of a final
release as soon as feasible, while new breaking development will continue
to occur on the master branch which will target a 0.5 release further down
the line.

Of special note is the fact that this change
 has changed the embedding
API, those of you special enough to be using that API, please take note
when testing against RC2.

I had originally tried to send this out to julia-news, but it looks like
forwarding as we had it setup doesn't work quite right.
-E

[julia-users] .cache directory in .julia

[David Anthoff]

Just curios, what is the .cache directory in the .julia directory?

 

For julia 0.3 it seems that directory was a child of the v0.3 directory, for
julia 0.4 it seems it moved one level up to be a sibling of the v0.4 folder.
Is there a reason for that?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

Re: [julia-users] Re: @sprintf with a format string

[Tom Breloff]

Sorry I wasn't expecting you to run it... just comment.  You'll have to do:

Pkg.rm("Formatting")
Pkg.clone("https://github.com/tbreloff/Formatting.jl.git;)
Pkg.checkout("Formatting", "tom-fmt")

Let me know if that works.

On Tue, Sep 22, 2015 at 5:52 PM, lawrence dworsky 
wrote:

> I'm afraid my beginner status with Julia is showing:
>
> I ran Pkg.add("Formatting"), and then   using Formatting   came back with
> a whole bunch of warnings, most about  Union(args...) being depricated, use
> Union(args) instead.
>
> When all is said and done,   fmt_default!  gives me a  UndefVarError.
>
> Help!
>
>
>
> On Tue, Sep 22, 2015 at 2:45 PM, Tom Breloff  wrote:
>
>> Thanks Larry, that's helpful.  Just for discussions sake, here's a quick
>> macro that calls my proposed `fmt` method under the hood, and does
>> something similar to what you showed.  What do you think about this style
>> (and what would you do differently)?
>>
>> using Formatting
>>
>> macro fmt(args...)
>>  expr = Expr(:block)
>>  expr.args = [:(print(fmt($(esc(arg))), "\t\t")) for arg in args]
>>  push!(expr.args, :(println()))
>>  expr
>> end
>>
>>
>> And then an example usage:
>>
>> In:
>>
>> x = 1010101
>> y = 55.5
>> fmt_default!(width=15)
>>
>> @fmt x y
>>
>> fmt_default!(Int, :commas)
>> fmt_default!(Float64, prec=2)
>>
>> @fmt x y
>>
>>
>> Out:
>>
>> 1010101  55.56
>>   1,010,101  55.56
>>
>>
>>
>> On Tuesday, September 22, 2015 at 3:08:35 PM UTC-4, lawrence dworsky
>> wrote:
>>>
>>> Hi Tom
>>>
>>> What I like about it is that you can just use print *, dumbly and it
>>> always provides useful, albeit not beautiful, results. When I'm writing a
>>> program, I use print statements very liberally to observe what's going on -
>>> I find this more convenient than an in-line debugger.
>>>
>>> As the last line in my program below shows, it's easy to switch to
>>> formatted output when you want to. The formatting capability is pretty
>>> thorough, I'm just showing a simple example.
>>>
>>> This Fortran program doesn't do anything, it just illustrates what the
>>> print statement produces:
>>>
>>>
>>> real x, y
>>> integer i, j
>>> complex z
>>> character*6  name
>>>
>>> x = 2.6
>>> y = -4.
>>> i = 36
>>> j = -40
>>> z = cmplx(17., 19.)
>>> name = 'Larry'
>>>
>>> print *, x, y, i, j, z
>>> print *, 'x = ', x, ' and j = ', j
>>> print *, 'Hello, ', name, j
>>> print '(2f8.3, i5)', x, y, j
>>>
>>> stop
>>> end
>>>
>>>
>>> The output is:
>>>
>>> 2.6 -4.0   36
>>> -40  (17., 19.)
>>> x = 2.6   and j =-40
>>> Hello, Larry -40
>>>   2.600   -4.000  -40
>>>
>>>
>>> Is this what you are looking for?
>>>
>>> Larry
>>>
>>>
>>>
>>> On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff  wrote:
>>>
 Larry: can you provide details on exactly what you like about Fortran's
 print statement?  Did it provide good defaults?  Was it easy to customize?

 On Tue, Sep 22, 2015 at 12:55 PM, LarryD  wrote:

> Something I miss from Fortran is the very convenient default "print *,
> . "  It handled almost 100% of my needs while working on a program and
> was easily replaced by real formatting when the time came. Is there any
> chance that Julia could get something like this?
>
> Thanks
>
>
> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti
> wrote:
>>
>> Dear all,
>>
>> I could use some help here, because I can't believe I'm not able to
>> easily print formatted numbers under Julia in a easy way. What I try to 
>> do
>> is to write a function that, given a vector, prints all its components 
>> with
>> a user-defined format. I was trying something of the form
>>
>> function Print_Vec(aux_VEC,form_VEC)
>> form_VEC :: ASCIIString
>> str_VEC  = "%16.8f"
>> for elem_VEC in aux_VEC
>> str_VEC += @sprintf(form_VEC,elem_VEC)
>> end
>> return str_VEC
>> end
>>
>> However, that doesn't work because it looks like the first argument
>> in @sprintf must be a explicit string, and not a variable.
>> Is there anything I can do with that?
>>
>> Thanks a lot for your help.
>>
>

>>>
>

Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

Hmm... I know it's horrible, but I just added that to my juliarc file :-)

This function is 100x slower than the macro, at about 100 lines in 0.5s. I
know that's horribly slow for traditional printf() but it's fast enough for
terminal output.


On 22 September 2015 at 22:06, Stefan Karpinski 
wrote:

> Possible, but I don't relish the thought of forever explaining to people
> that they need to use printf with or without the @ depending on if they
> want it to be fast or flexible. If you really don't care about speed, you
> can just do this right now:
>
> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
> $(args...))
>
>
> But actually don't do that because it's so horrifically slow and
> inefficient I just can't.
>
> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera 
> wrote:
>
>>
>> On 22 September 2015 at 20:40, Stefan Karpinski 
>> wrote:
>>
>>> I think that before any further discussion takes place of how easy or
>>> hard implementing a high-performance printf is, anyone who'd like to
>>> comment should spend some time perusing GNU libc's vfprintf
>>> implementation
>>> .
>>> This code is neither easy nor trivial – it's batsh*t crazy.
>>>
>>
>> That is insane... 2388 lines, half of it macros, and I have no idea how
>> it works.
>>
>>
>>
>>> And we want to match its performance yet be much more flexible and
>>> generic. The current printf implementation does just that, while being
>>> somewhat less insane GNU's printf code. If someone has bright ideas for how
>>> to *also* allow runtime format specification without sacrificing
>>> performance or generality, I'm all ears.
>>>
>>
>>
>> This might be a stupid question, but what's the harm in sacrificing
>> performance as long as we keep the current @sprintf for scenarios that call
>> for performance? I don't always need printf() to be fast.
>>
>>
>>
>>
>>> I have some thoughts, but they're just that – thoughts. One option is to
>>> change the design and avoid printf-style formatting altogether. But then
>>> I'm sure I'll never hear the end of it with people kvetching about how we
>>> don't have printf.
>>>
>>
>> Probably. Everyone is used to printf and they are comfortable with it.
>>
>> Daniel.
>>
>
>

Re: [julia-users] Re: @sprintf with a format string

[lawrence dworsky]

I'm afraid my beginner status with Julia is showing:

I ran Pkg.add("Formatting"), and then   using Formatting   came back with a
whole bunch of warnings, most about  Union(args...) being depricated, use
Union(args) instead.

When all is said and done,   fmt_default!  gives me a  UndefVarError.

Help!



On Tue, Sep 22, 2015 at 2:45 PM, Tom Breloff  wrote:

> Thanks Larry, that's helpful.  Just for discussions sake, here's a quick
> macro that calls my proposed `fmt` method under the hood, and does
> something similar to what you showed.  What do you think about this style
> (and what would you do differently)?
>
> using Formatting
>
> macro fmt(args...)
>  expr = Expr(:block)
>  expr.args = [:(print(fmt($(esc(arg))), "\t\t")) for arg in args]
>  push!(expr.args, :(println()))
>  expr
> end
>
>
> And then an example usage:
>
> In:
>
> x = 1010101
> y = 55.5
> fmt_default!(width=15)
>
> @fmt x y
>
> fmt_default!(Int, :commas)
> fmt_default!(Float64, prec=2)
>
> @fmt x y
>
>
> Out:
>
> 1010101  55.56
>   1,010,101  55.56
>
>
>
> On Tuesday, September 22, 2015 at 3:08:35 PM UTC-4, lawrence dworsky wrote:
>>
>> Hi Tom
>>
>> What I like about it is that you can just use print *, dumbly and it
>> always provides useful, albeit not beautiful, results. When I'm writing a
>> program, I use print statements very liberally to observe what's going on -
>> I find this more convenient than an in-line debugger.
>>
>> As the last line in my program below shows, it's easy to switch to
>> formatted output when you want to. The formatting capability is pretty
>> thorough, I'm just showing a simple example.
>>
>> This Fortran program doesn't do anything, it just illustrates what the
>> print statement produces:
>>
>>
>> real x, y
>> integer i, j
>> complex z
>> character*6  name
>>
>> x = 2.6
>> y = -4.
>> i = 36
>> j = -40
>> z = cmplx(17., 19.)
>> name = 'Larry'
>>
>> print *, x, y, i, j, z
>> print *, 'x = ', x, ' and j = ', j
>> print *, 'Hello, ', name, j
>> print '(2f8.3, i5)', x, y, j
>>
>> stop
>> end
>>
>>
>> The output is:
>>
>> 2.6 -4.0   36 -40
>>  (17., 19.)
>> x = 2.6   and j =-40
>> Hello, Larry -40
>>   2.600   -4.000  -40
>>
>>
>> Is this what you are looking for?
>>
>> Larry
>>
>>
>>
>> On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff  wrote:
>>
>>> Larry: can you provide details on exactly what you like about Fortran's
>>> print statement?  Did it provide good defaults?  Was it easy to customize?
>>>
>>> On Tue, Sep 22, 2015 at 12:55 PM, LarryD  wrote:
>>>
 Something I miss from Fortran is the very convenient default "print *,
 . "  It handled almost 100% of my needs while working on a program and
 was easily replaced by real formatting when the time came. Is there any
 chance that Julia could get something like this?

 Thanks


 On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti
 wrote:
>
> Dear all,
>
> I could use some help here, because I can't believe I'm not able to
> easily print formatted numbers under Julia in a easy way. What I try to do
> is to write a function that, given a vector, prints all its components 
> with
> a user-defined format. I was trying something of the form
>
> function Print_Vec(aux_VEC,form_VEC)
> form_VEC :: ASCIIString
> str_VEC  = "%16.8f"
> for elem_VEC in aux_VEC
> str_VEC += @sprintf(form_VEC,elem_VEC)
> end
> return str_VEC
> end
>
> However, that doesn't work because it looks like the first argument in
> @sprintf must be a explicit string, and not a variable.
> Is there anything I can do with that?
>
> Thanks a lot for your help.
>

>>>
>>

Re: [julia-users] Re: Juno stopped working - error message

[Haoran Jiang]

Hi Spencer:
Thanks for the reply! However, I just tried the method you told me but it 
still doesn't work. 
I also tried to pinned back everything just like how Serge was doing, but 
it still doesn't work, here is my status now.


在 2015年9月22日星期二 UTC-7上午11:13:50，Spencer Russell写道：
>
> Hi Haoran,
>  
> Try pinning the Compat package by running `Pkg.pin("Compat", v"0.7.0")`
>  
> If you're running Julia 0.3.11 that should be the newest version that will 
> install, so I'm not sure how you ended up with Compat 0.7.3 (which is 
> currently tagged to be 0.4 and newer). That's a pretty recent change 
> though(yesterday evening), but if you just installed today I'd think you'd 
> be good to go.
>  
> -s
>  
>  
> On Tue, Sep 22, 2015, at 02:58 AM, Haoran Jiang wrote:
>
> Hi Greg, I am new to Julia and Juno, I just installed this software today 
> and I have the same error message as you do, can you tell me what did you 
> do to make it right? this is my Pkg.status. I never had it worked 
> before(since it is my first day install it) so i dont know what file to 
> change and where to change them, Thanks!
>  
>  
> 在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
>
> Serge,
>  
> Below is output of Pkg.status():
>  
> I had previously tried removing many packages, but nothing is pinned (so 
> not sure if rolling back will result in same config)
>  
> The only error message I receive using Juno is:
> symbol could not be found jl_generating_output (-1): The specified 
> procedure could not be found.
>  
> but after this everything seems to work as normal.
>  
> Hope this helps.
> -- Greg
>  
>  
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
> julia> Pkg.status()
> 9 required packages:
>  - Dates 0.3.2
>  - Distributions 0.8.6
>  - HDF5  0.5.5
>  - ImageView 0.1.16
>  - Images0.4.47
>  - JLD   0.5.4
>  - Jewel 1.0.6
>  - Optim 0.4.2
>  - ZMQ   0.2.0
> 39 additional packages:
>  - ArrayViews0.6.3
>  - BinDeps   0.3.15
>  - Blosc 0.1.4
>  - Cairo 0.2.30
>  - Calculus  0.1.10
>  - ColorTypes0.1.4
>  - ColorVectorSpace  0.0.3
>  - Colors0.5.3
>  - Compat0.7.1
>  - Compose   0.3.15
>  - DataStructures0.3.12
>  - Docile0.5.18
>  - DualNumbers   0.1.3
>  - FactCheck 0.4.0
>  - FixedPointNumbers 0.0.10
>  - Graphics  0.1.0
>  - HttpCommon0.1.2
>  - IniFile   0.2.4
>  - Iterators 0.1.8
>  - JSON  0.4.5
>  - JuliaParser   0.6.2
>  - LNR   0.0.1
>  - Lazy  0.10.0
>  - LibExpat  0.0.8
>  - MacroTools0.2.0
>  - NaNMath   0.1.0
>  - PDMats0.3.5
>  - Reexport  0.0.3
>  - Requires  0.2.0
>  - SHA   0.1.1
>  - SIUnits   0.0.5
>  - StatsBase 0.7.2
>  - StatsFuns 0.1.3
>  - TexExtensions 0.0.2
>  - Tk0.3.6
>  - URIParser 0.0.7
>  - WinRPM0.1.12
>  - Winston   0.11.12
>  - Zlib  0.1.9
> Julia>
>
>  
>  
>  
> On Monday, September 21, 2015 at 9:44:24 AM UTC+10, Serge Santos wrote:
>
> Hi All,
>  
> I tried to roll back to JuliaParser v0.6.2 and it didn't work. 
>  
> If someone still manages to successfully run Juno with Julia 0.3.11, can 
> you please send the list of packages with version numbers that does not 
> create any issues with Juno (i.e,, output from Pkg.status()). I was not 
> able to figure out what combination of versions work. 
>  
> Many thanks in advance
> Serge
>  
> On Monday, 21 September 2015 00:16:27 UTC+1, Greg Plowman wrote:
>
> Hi All,
>  
> On 2 different PCs where Juno works (almost without error) Pkg.status() 
> reports JuliaParser v0.6.2
> On PC that has Juno errors, Pkg.status() reports JuliaParser v0.6.3
> Rolling back to JuliaParser v0.1.2 creates different errors.
> So it seems we need to revert to JuliaParser v0.6.2
>  
> I'm not at a PC where I can 

Re: [julia-users] Re: Juno stopped working - error message

[Haoran Jiang]

here is the screen copy of my error message,what do you suggest i to do?



在 2015年9月22日星期二 UTC-7下午8:50:00，Spencer Russell写道：
>
> Can you cut/paste your session with the error into a gist? That might help 
> track down more specifically what’s causing the issue.
>
> -s
>
> On Sep 22, 2015, at 11:46 PM, Haoran Jiang  > wrote:
>
> Hi Spencer:
> Thanks for the reply! However, I just tried the method you told me but it 
> still doesn't work. 
> I also tried to pinned back everything just like how Serge was doing, but 
> it still doesn't work, here is my status now.
>
>
> 在 2015年9月22日星期二 UTC-7上午11:13:50，Spencer Russell写道：
>
> Hi Haoran,
>  
> Try pinning the Compat package by running `Pkg.pin("Compat", v"0.7.0")`
>  
> If you're running Julia 0.3.11 that should be the newest version that will 
> install, so I'm not sure how you ended up with Compat 0.7.3 (which is 
> currently tagged to be 0.4 and newer). That's a pretty recent change 
> though(yesterday evening), but if you just installed today I'd think you'd 
> be good to go.
>  
> -s
>  
>  
> On Tue, Sep 22, 2015, at 02:58 AM, Haoran Jiang wrote:
>
> Hi Greg, I am new to Julia and Juno, I just installed this software today 
> and I have the same error message as you do, can you tell me what did you 
> do to make it right? this is my Pkg.status. I never had it worked 
> before(since it is my first day install it) so i dont know what file to 
> change and where to change them, Thanks!
>  
>  
> 在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
>
> Serge,
>  
> Below is output of Pkg.status():
>  
> I had previously tried removing many packages, but nothing is pinned (so 
> not sure if rolling back will result in same config)
>  
> The only error message I receive using Juno is:
> symbol could not be found jl_generating_output (-1): The specified 
> procedure could not be found.
>  
> but after this everything seems to work as normal.
>  
> Hope this helps.
> -- Greg
>  
>  
>
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
> |__/   |  x86_64-w64-mingw32
> julia> Pkg.status()
> 9 required packages:
>  - Dates 0.3.2
>  - Distributions 0.8.6
>  - HDF5  0.5.5
>  - ImageView 0.1.16
>  - Images0.4.47
>  - JLD   0.5.4
>  - Jewel 1.0.6
>  - Optim 0.4.2
>  - ZMQ   0.2.0
> 39 additional packages:
>  - ArrayViews0.6.3
>  - BinDeps   0.3.15
>  - Blosc 0.1.4
>  - Cairo 0.2.30
>  - Calculus  0.1.10
>  - ColorTypes0.1.4
>  - ColorVectorSpace  0.0.3
>  - Colors0.5.3
>  - Compat0.7.1
>  - Compose   0.3.15
>  - DataStructures0.3.12
>  - Docile0.5.18
>  - DualNumbers   0.1.3
>  - FactCheck 0.4.0
>  - FixedPointNumbers 0.0.10
>  - Graphics  0.1.0
>  - HttpCommon0.1.2
>  - IniFile   0.2.4
>  - Iterators 0.1.8
>  - JSON  0.4.5
>  - JuliaParser   0.6.2
>  - LNR   0.0.1
>  - Lazy  0.10.0
>  - LibExpat  0.0.8
>  - MacroTools0.2.0
>  - NaNMath   0.1.0
>  - PDMats0.3.5
>  - Reexport  0.0.3
>  - Requires  0.2.0
>  - SHA   0.1.1
>  - SIUnits   0.0.5
>  - StatsBase 0.7.2
>  - StatsFuns 0.1.3
>  - TexExtensions 0.0.2
>  - Tk0.3.6
>  - URIParser 0.0.7
>  - WinRPM0.1.12
>  - Winston   0.11.12
>  - Zlib  0.1.9
> Julia>
>
>  
>  
>  
> On Monday, September 21, 2015 at 9:44:24 AM UTC+10, Serge Santos wrote:
>
> Hi All,
>  
> I tried to roll back to JuliaParser v0.6.2 and it didn't work. 
>  
> If someone still manages to successfully run Juno with Julia 0.3.11, can 
> you please send the list of packages with version numbers that does not 
> create any issues with Juno (i.e,, output from Pkg.status()). I was not 
> able to figure out what combination of versions work. 
>  
> Many thanks in advance
> Serge
>  
> On Monday, 21 September 2015 00:16:27 

Re: [julia-users] Re: Juno stopped working - error message

[Spencer Russell]

Can you cut/paste your session with the error into a gist? That might help 
track down more specifically what’s causing the issue.

-s

> On Sep 22, 2015, at 11:46 PM, Haoran Jiang  wrote:
> 
> Hi Spencer:
> Thanks for the reply! However, I just tried the method you told me but it 
> still doesn't work. 
> I also tried to pinned back everything just like how Serge was doing, but it 
> still doesn't work, here is my status now.
> 
> 
> 在 2015年9月22日星期二 UTC-7上午11:13:50，Spencer Russell写道：
> Hi Haoran,
>  
> Try pinning the Compat package by running `Pkg.pin("Compat", v"0.7.0")`
>  
> If you're running Julia 0.3.11 that should be the newest version that will 
> install, so I'm not sure how you ended up with Compat 0.7.3 (which is 
> currently tagged to be 0.4 and newer). That's a pretty recent change 
> though(yesterday evening), but if you just installed today I'd think you'd be 
> good to go.
>  
> -s
>  
>  
> On Tue, Sep 22, 2015, at 02:58 AM, Haoran Jiang wrote:
> Hi Greg, I am new to Julia and Juno, I just installed this software today and 
> I have the same error message as you do, can you tell me what did you do to 
> make it right? this is my Pkg.status. I never had it worked before(since it 
> is my first day install it) so i dont know what file to change and where to 
> change them, Thanks!
>  
>  
> 在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
> Serge,
>  
> Below is output of Pkg.status():
>  
> I had previously tried removing many packages, but nothing is pinned (so not 
> sure if rolling back will result in same config)
>  
> The only error message I receive using Juno is:
> symbol could not be found jl_generating_output (-1): The specified 
> procedure could not be found.
>  
> but after this everything seems to work as normal.
>  
> Hope this helps.
> -- Greg
>  
>  
> 
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org 
> 
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ 
>  release
> |__/   |  x86_64-w64-mingw32
> julia> Pkg.status()
> 9 required packages:
>  - Dates 0.3.2
>  - Distributions 0.8.6
>  - HDF5  0.5.5
>  - ImageView 0.1.16
>  - Images0.4.47
>  - JLD   0.5.4
>  - Jewel 1.0.6
>  - Optim 0.4.2
>  - ZMQ   0.2.0
> 39 additional packages:
>  - ArrayViews0.6.3
>  - BinDeps   0.3.15
>  - Blosc 0.1.4
>  - Cairo 0.2.30
>  - Calculus  0.1.10
>  - ColorTypes0.1.4
>  - ColorVectorSpace  0.0.3
>  - Colors0.5.3
>  - Compat0.7.1
>  - Compose   0.3.15
>  - DataStructures0.3.12
>  - Docile0.5.18
>  - DualNumbers   0.1.3
>  - FactCheck 0.4.0
>  - FixedPointNumbers 0.0.10
>  - Graphics  0.1.0
>  - HttpCommon0.1.2
>  - IniFile   0.2.4
>  - Iterators 0.1.8
>  - JSON  0.4.5
>  - JuliaParser   0.6.2
>  - LNR   0.0.1
>  - Lazy  0.10.0
>  - LibExpat  0.0.8
>  - MacroTools0.2.0
>  - NaNMath   0.1.0
>  - PDMats0.3.5
>  - Reexport  0.0.3
>  - Requires  0.2.0
>  - SHA   0.1.1
>  - SIUnits   0.0.5
>  - StatsBase 0.7.2
>  - StatsFuns 0.1.3
>  - TexExtensions 0.0.2
>  - Tk0.3.6
>  - URIParser 0.0.7
>  - WinRPM0.1.12
>  - Winston   0.11.12
>  - Zlib  0.1.9
> Julia>
> 
>  
>  
>  
> On Monday, September 21, 2015 at 9:44:24 AM UTC+10, Serge Santos wrote:
> Hi All,
>  
> I tried to roll back to JuliaParser v0.6.2 and it didn't work. 
>  
> If someone still manages to successfully run Juno with Julia 0.3.11, can you 
> please send the list of packages with version numbers that does not create 
> any issues with Juno (i.e,, output from Pkg.status()). I was not able to 
> figure out what combination of versions work. 
>  
> Many thanks in advance
> Serge
>  
> On Monday, 21 September 2015 00:16:27 UTC+1, Greg Plowman wrote:
> Hi All,
>  
> On 2 different PCs where Juno works 

Re: [julia-users] Juno stopped working - error message

[Spencer Russell]

Is it possible you have multiple versions of Julia installed, or maybe leftover 
packages in your .julia folder from a previous installation?  It might be worth 
trying to delete (or move out of the way) your .julia directory and re-install 
the packages.

Also if possible can you include the whole backtrace, not just the last part 
with the error message? That’s helpful to see what chain of function calls is 
actually triggering the error.

-s

> On Sep 23, 2015, at 12:54 AM, Haoran Jiang  wrote:
> 
> here is the screen copy of my error message,what do you suggest i to do?
> 
> 
> 
> 在 2015年9月22日星期二 UTC-7下午8:50:00，Spencer Russell写道：
> Can you cut/paste your session with the error into a gist? That might help 
> track down more specifically what’s causing the issue.
> 
> -s
> 
> On Sep 22, 2015, at 11:46 PM, Haoran Jiang  > wrote:
> 
> Hi Spencer:
> Thanks for the reply! However, I just tried the method you told me but it 
> still doesn't work. 
> I also tried to pinned back everything just like how Serge was doing, but it 
> still doesn't work, here is my status now.
> 
> 
> 在 2015年9月22日星期二 UTC-7上午11:13:50，Spencer Russell写道：
> Hi Haoran,
>  
> Try pinning the Compat package by running `Pkg.pin("Compat", v"0.7.0")`
>  
> If you're running Julia 0.3.11 that should be the newest version that will 
> install, so I'm not sure how you ended up with Compat 0.7.3 (which is 
> currently tagged to be 0.4 and newer). That's a pretty recent change 
> though(yesterday evening), but if you just installed today I'd think you'd be 
> good to go.
>  
> -s
>  
>  
> On Tue, Sep 22, 2015, at 02:58 AM, Haoran Jiang wrote:
> Hi Greg, I am new to Julia and Juno, I just installed this software today and 
> I have the same error message as you do, can you tell me what did you do to 
> make it right? this is my Pkg.status. I never had it worked before(since it 
> is my first day install it) so i dont know what file to change and where to 
> change them, Thanks!
>  
>  
> 在 2015年9月20日星期日 UTC-7下午6:09:56，Greg Plowman写道：
> Serge,
>  
> Below is output of Pkg.status():
>  
> I had previously tried removing many packages, but nothing is pinned (so not 
> sure if rolling back will result in same config)
>  
> The only error message I receive using Juno is:
> symbol could not be found jl_generating_output (-1): The specified 
> procedure could not be found.
>  
> but after this everything seems to work as normal.
>  
> Hope this helps.
> -- Greg
>  
>  
> 
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org 
> 
>_ _   _| |_  __ _   |  Type "help()" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.3.11 (2015-07-27 06:18 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ 
>  release
> |__/   |  x86_64-w64-mingw32
> julia> Pkg.status()
> 9 required packages:
>  - Dates 0.3.2
>  - Distributions 0.8.6
>  - HDF5  0.5.5
>  - ImageView 0.1.16
>  - Images0.4.47
>  - JLD   0.5.4
>  - Jewel 1.0.6
>  - Optim 0.4.2
>  - ZMQ   0.2.0
> 39 additional packages:
>  - ArrayViews0.6.3
>  - BinDeps   0.3.15
>  - Blosc 0.1.4
>  - Cairo 0.2.30
>  - Calculus  0.1.10
>  - ColorTypes0.1.4
>  - ColorVectorSpace  0.0.3
>  - Colors0.5.3
>  - Compat0.7.1
>  - Compose   0.3.15
>  - DataStructures0.3.12
>  - Docile0.5.18
>  - DualNumbers   0.1.3
>  - FactCheck 0.4.0
>  - FixedPointNumbers 0.0.10
>  - Graphics  0.1.0
>  - HttpCommon0.1.2
>  - IniFile   0.2.4
>  - Iterators 0.1.8
>  - JSON  0.4.5
>  - JuliaParser   0.6.2
>  - LNR   0.0.1
>  - Lazy  0.10.0
>  - LibExpat  0.0.8
>  - MacroTools0.2.0
>  - NaNMath   0.1.0
>  - PDMats0.3.5
>  - Reexport  0.0.3
>  - Requires  0.2.0
>  - SHA   0.1.1
>  - SIUnits   0.0.5
>  - StatsBase 0.7.2
>  - StatsFuns 0.1.3
>  - TexExtensions 0.0.2
>  - Tk0.3.6
>  - URIParser 0.0.7
>  - WinRPM0.1.12
>  - Winston  

Re: [julia-users] Re: @sprintf with a format string

[elextr]

Tim,

How well does it work if, instead of pi, the thing being printed is some 
abstract type so its concrete type is only known at runtime?

Cheers
Lex

On Wednesday, September 23, 2015 at 11:34:27 AM UTC+10, Tim Holy wrote:
>
> On Tuesday, September 22, 2015 05:21:10 PM Luke Stagner wrote: 
> > Would it be possible to rewrite @printf as a generated function instead 
> of 
> > a macro. That way the calling syntax would be more familiar. 
>
> That's a good suggestion. 
>
> At the risk of encouraging emacs users to "fix" the syntax with ctrl-T, 
> I'd 
> propose the following (apparently complete?) solution: 
>
>
> immutable FormatString{S} end 
>
> FormatString(str::AbstractString) = FormatString{symbol(str)} 
>
> macro f_str(arg) 
> :(FormatString{symbol($arg)}) 
> end 
>
> @generated function Base.print{format}(::Type{FormatString{format}}, 
> args...) 
> meta = Expr(:meta, :inline) 
> fmt = string(format) 
> allargs = [:(args[$d]) for d = 1:length(args)] 
> quote 
> @printf($fmt, $(allargs...)) 
> end 
> end 
>
>
>
> Demo: 
> julia> print(f"%.3f", pi) 
> 3.142 
> julia> function foo(strs) 
>for str in strs 
>print(FormatString(str), pi) 
>end 
>end 
> foo (generic function with 1 method) 
>
> julia> strs = ("%.3f\n", "%.5f\n") 
> ("%.3f\n","%.5f\n") 
>
> julia> foo(strs) 
> 3.142 
> 3.14159 
>
> julia> @time 1   # just to warm up @time 
>   0.04 seconds (148 allocations: 10.151 KB) 
> 1 
>
> julia> @time foo(strs) 
> 3.142 
> 3.14159 
>   0.000106 seconds (18 allocations: 704 bytes) 
>
>
> Nice that we get to re-use the macro that Stefan worked so hard on! 
>
> Best, 
> --Tim 
>
> > 
> > On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski 
> wrote: 
> > > Possible, but I don't relish the thought of forever explaining to 
> people 
> > > that they need to use printf with or without the @ depending on if 
> they 
> > > want it to be fast or flexible. If you really don't care about speed, 
> you 
> > > can just do this right now: 
> > > 
> > > printf(fmt::AbstractString, args...) = @eval 
> @printf($(bytestring(fmt)), 
> > > $(args...)) 
> > > 
> > > 
> > > But actually don't do that because it's so horrifically slow and 
> > > inefficient I just can't. 
> > > 
> > > On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  > > 
> > > > wrote: 
> > >> On 22 September 2015 at 20:40, Stefan Karpinski  > >> 
> > >> > wrote: 
> > >>> I think that before any further discussion takes place of how easy 
> or 
> > >>> hard implementing a high-performance printf is, anyone who'd like to 
> > >>> comment should spend some time perusing GNU libc's vfprintf 
> > >>> implementation 
> > >>> <
> http://repo.or.cz/w/glibc.git/blob/ec999b8e5ede67f42759657beb8c5fef87c8 
> > >>> cc63:/stdio-common/vfprintf.c>. This code is neither easy nor 
> trivial – 
> > >>> it's batsh*t crazy. 
> > >> 
> > >> That is insane... 2388 lines, half of it macros, and I have no idea 
> how 
> > >> it works. 
> > >> 
> > >>> And we want to match its performance yet be much more flexible and 
> > >>> generic. The current printf implementation does just that, while 
> being 
> > >>> somewhat less insane GNU's printf code. If someone has bright ideas 
> for 
> > >>> how 
> > >>> to *also* allow runtime format specification without sacrificing 
> > >>> performance or generality, I'm all ears. 
> > >> 
> > >> This might be a stupid question, but what's the harm in sacrificing 
> > >> performance as long as we keep the current @sprintf for scenarios 
> that 
> > >> call 
> > >> for performance? I don't always need printf() to be fast. 
> > >> 
> > >>> I have some thoughts, but they're just that – thoughts. One option 
> is to 
> > >>> change the design and avoid printf-style formatting altogether. But 
> then 
> > >>> I'm sure I'll never hear the end of it with people kvetching about 
> how 
> > >>> we 
> > >>> don't have printf. 
> > >> 
> > >> Probably. Everyone is used to printf and they are comfortable with 
> it. 
> > >> 
> > >> Daniel. 
>
>

Re: [julia-users] Re: @sprintf with a format string

[elextr]

Stefan, don't beat yourself up so much :)

Sometimes the choice of fast or flexible just has to be made.  Maybe call 
them @fast_printf() and printf() (after appropriate deprecation time of 
course).  So long as the flexible printf is "adequate" performance (as 
Rolls Royce used to say).

Then if your ideas for flexible printf work out they can improve it over 
time, as convenient.

And of course other non-printf APIs can be added (but please don't 
(re)invent C++ << :).

Cheers
Lex

On Wednesday, September 23, 2015 at 6:07:23 AM UTC+10, Stefan Karpinski 
wrote:
>
> Possible, but I don't relish the thought of forever explaining to people 
> that they need to use printf with or without the @ depending on if they 
> want it to be fast or flexible. If you really don't care about speed, you 
> can just do this right now:
>
> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)), 
> $(args...))
>
>
> But actually don't do that because it's so horrifically slow and 
> inefficient I just can't.
>
> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  > wrote:
>
>>
>> On 22 September 2015 at 20:40, Stefan Karpinski > > wrote:
>>
>>> I think that before any further discussion takes place of how easy or 
>>> hard implementing a high-performance printf is, anyone who'd like to 
>>> comment should spend some time perusing GNU libc's vfprintf 
>>> implementation 
>>> .
>>>  
>>> This code is neither easy nor trivial – it's batsh*t crazy.
>>>
>>
>> That is insane... 2388 lines, half of it macros, and I have no idea how 
>> it works.
>>
>>  
>>
>>> And we want to match its performance yet be much more flexible and 
>>> generic. The current printf implementation does just that, while being 
>>> somewhat less insane GNU's printf code. If someone has bright ideas for how 
>>> to *also* allow runtime format specification without sacrificing 
>>> performance or generality, I'm all ears.
>>>
>>
>>
>> This might be a stupid question, but what's the harm in sacrificing 
>> performance as long as we keep the current @sprintf for scenarios that call 
>> for performance? I don't always need printf() to be fast.
>>
>>
>>  
>>
>>> I have some thoughts, but they're just that – thoughts. One option is to 
>>> change the design and avoid printf-style formatting altogether. But then 
>>> I'm sure I'll never hear the end of it with people kvetching about how we 
>>> don't have printf.
>>>
>>
>> Probably. Everyone is used to printf and they are comfortable with it.
>>
>> Daniel.
>>
>
>

Re: [julia-users] Re: @sprintf with a format string

[Luke Stagner]

Would it be possible to rewrite @printf as a generated function instead of 
a macro. That way the calling syntax would be more familiar.

On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski wrote:
>
> Possible, but I don't relish the thought of forever explaining to people 
> that they need to use printf with or without the @ depending on if they 
> want it to be fast or flexible. If you really don't care about speed, you 
> can just do this right now:
>
> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)), 
> $(args...))
>
>
> But actually don't do that because it's so horrifically slow and 
> inefficient I just can't.
>
> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  > wrote:
>
>>
>> On 22 September 2015 at 20:40, Stefan Karpinski > > wrote:
>>
>>> I think that before any further discussion takes place of how easy or 
>>> hard implementing a high-performance printf is, anyone who'd like to 
>>> comment should spend some time perusing GNU libc's vfprintf 
>>> implementation 
>>> .
>>>  
>>> This code is neither easy nor trivial – it's batsh*t crazy.
>>>
>>
>> That is insane... 2388 lines, half of it macros, and I have no idea how 
>> it works.
>>
>>  
>>
>>> And we want to match its performance yet be much more flexible and 
>>> generic. The current printf implementation does just that, while being 
>>> somewhat less insane GNU's printf code. If someone has bright ideas for how 
>>> to *also* allow runtime format specification without sacrificing 
>>> performance or generality, I'm all ears.
>>>
>>
>>
>> This might be a stupid question, but what's the harm in sacrificing 
>> performance as long as we keep the current @sprintf for scenarios that call 
>> for performance? I don't always need printf() to be fast.
>>
>>
>>  
>>
>>> I have some thoughts, but they're just that – thoughts. One option is to 
>>> change the design and avoid printf-style formatting altogether. But then 
>>> I'm sure I'll never hear the end of it with people kvetching about how we 
>>> don't have printf.
>>>
>>
>> Probably. Everyone is used to printf and they are comfortable with it.
>>
>> Daniel.
>>
>
>

Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

Really? What does it *DO* that needs 1MB? I admit I don't really know how
it works. I have tried to learn macros, but I still think they are
basically black magic.


On 22 September 2015 at 22:37, Stefan Karpinski 
wrote:

> It also allocates 1MB just to print three numbers. Yikes.
>
> On Tue, Sep 22, 2015 at 4:34 PM, Daniel Carrera 
> wrote:
>
>> Hmm... I know it's horrible, but I just added that to my juliarc file :-)
>>
>> This function is 100x slower than the macro, at about 100 lines in 0.5s.
>> I know that's horribly slow for traditional printf() but it's fast enough
>> for terminal output.
>>
>>
>>
>> On 22 September 2015 at 22:06, Stefan Karpinski 
>> wrote:
>>
>>> Possible, but I don't relish the thought of forever explaining to people
>>> that they need to use printf with or without the @ depending on if they
>>> want it to be fast or flexible. If you really don't care about speed, you
>>> can just do this right now:
>>>
>>> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
>>> $(args...))
>>>
>>>
>>> But actually don't do that because it's so horrifically slow and
>>> inefficient I just can't.
>>>
>>> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera 
>>> wrote:
>>>

 On 22 September 2015 at 20:40, Stefan Karpinski 
 wrote:

> I think that before any further discussion takes place of how easy or
> hard implementing a high-performance printf is, anyone who'd like to
> comment should spend some time perusing GNU libc's vfprintf
> implementation
> .
> This code is neither easy nor trivial – it's batsh*t crazy.
>

 That is insane... 2388 lines, half of it macros, and I have no idea how
 it works.



> And we want to match its performance yet be much more flexible and
> generic. The current printf implementation does just that, while being
> somewhat less insane GNU's printf code. If someone has bright ideas for 
> how
> to *also* allow runtime format specification without sacrificing
> performance or generality, I'm all ears.
>


 This might be a stupid question, but what's the harm in sacrificing
 performance as long as we keep the current @sprintf for scenarios that call
 for performance? I don't always need printf() to be fast.




> I have some thoughts, but they're just that – thoughts. One option is
> to change the design and avoid printf-style formatting altogether. But 
> then
> I'm sure I'll never hear the end of it with people kvetching about how we
> don't have printf.
>

 Probably. Everyone is used to printf and they are comfortable with it.

 Daniel.

>>>
>>>
>>
>

Re: [julia-users] Re: @sprintf with a format string

[Tom Breloff]

I think not Luke.  Generated functions work on the types of the arguments.
If someone wants to format based on an input string, then you either need a
hardcoded value which can go into a macro, or a dynamic value that would go
in a normal function.

If all you want to do is print out some arbitrary list of objects with
pre-defined format, then a normal function should be plenty fast (and if
it's a fixed format string, the current macro is the way to go).

On Tue, Sep 22, 2015 at 8:21 PM, Luke Stagner  wrote:

> Would it be possible to rewrite @printf as a generated function instead of
> a macro. That way the calling syntax would be more familiar.
>
> On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski wrote:
>>
>> Possible, but I don't relish the thought of forever explaining to people
>> that they need to use printf with or without the @ depending on if they
>> want it to be fast or flexible. If you really don't care about speed, you
>> can just do this right now:
>>
>> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)),
>> $(args...))
>>
>>
>> But actually don't do that because it's so horrifically slow and
>> inefficient I just can't.
>>
>> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera 
>> wrote:
>>
>>>
>>> On 22 September 2015 at 20:40, Stefan Karpinski 
>>> wrote:
>>>
 I think that before any further discussion takes place of how easy or
 hard implementing a high-performance printf is, anyone who'd like to
 comment should spend some time perusing GNU libc's vfprintf
 implementation
 .
 This code is neither easy nor trivial – it's batsh*t crazy.

>>>
>>> That is insane... 2388 lines, half of it macros, and I have no idea how
>>> it works.
>>>
>>>
>>>
 And we want to match its performance yet be much more flexible and
 generic. The current printf implementation does just that, while being
 somewhat less insane GNU's printf code. If someone has bright ideas for how
 to *also* allow runtime format specification without sacrificing
 performance or generality, I'm all ears.

>>>
>>>
>>> This might be a stupid question, but what's the harm in sacrificing
>>> performance as long as we keep the current @sprintf for scenarios that call
>>> for performance? I don't always need printf() to be fast.
>>>
>>>
>>>
>>>
 I have some thoughts, but they're just that – thoughts. One option is
 to change the design and avoid printf-style formatting altogether. But then
 I'm sure I'll never hear the end of it with people kvetching about how we
 don't have printf.

>>>
>>> Probably. Everyone is used to printf and they are comfortable with it.
>>>
>>> Daniel.
>>>
>>
>>

[julia-users] Re: @sprintf with a format string

[Tomas Lycken]

By the way, you might also note that the Formatting.jl package is written 
and maintained by people who are all active contributors to the main 
language repo, and very active members of the community. Even if it's 
"external" in terms of how you install it, it's by no means external "in 
spirit".

// T

On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:
>
> Julia is a young language.
>
> This comes with a lot of benefits - for example, it's possible to do 
> things *right* from the start. We're currently in a phase where there is a 
> multitude of possible solutions to every problem that arises, and we 
> honestly don't know which solution proves to be the best one. Testing 
> various solutions out in packages, outside of the base distribution, where 
> they can compete for popularity, and keep building on top of each-other 
> until we reach something which we believe not only is adequate, but 
> *really* hits the sweet spot. In other words: sure, formatting numeric 
> output is fundamental, but it's a problem with a large solution space, and 
> we don't want to lock in on one path yet.
>
> But Julia's young age also means that there are lots of problems that 
> aren't really solved yet, or that have solutions proposed but not 
> implemented, etc. For the future, there are plans to include some packages 
> (which ones have not been decided, or AFAIK really even discussed) in a 
> sort-of "base distribution", so they will be installed upon installation of 
> Julia, and available with a single `using` statement. But the 
> infrastructure for this is not in place yet, and even if it were, there 
> would still be lots of reasons not to make a final decision on which 
> packages make the cut until we approach a 1.0 release of the language.
>
> So yeah, it might seem silly to have to install a package just to get 
> fine-grained control of numeric output formatting, but, at least for now, 
> that's part of what one could call Julia's "Package Deal" ;)
>
> // T
>
> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti wrote:
>>
>> Thanks, that seems to work.
>> Still it amazes me how Julia, being a language made for numerical 
>> calculations, does not natively support a simple mechanism to print/write 
>> large bunches of numbers. I've been in the numerical world for 20+ years 
>> and I know printing lots of numbers is something you get on a daily
>> basis. I know now the formatting package can help on that (thanks :), 
>> what I do not like is the idea of having to install every time a new package
>> to get added functionality. I understand there are things that have to go 
>> to external packages because of its limited or specialized use, but
>> come on... printing number os definitely not one of those.
>> Just my 2cents :)
>>
>> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly 
>> wrote:
>>>
>>> https://github.com/JuliaLang/Formatting.jl might help.
>>>
>>> — Mike
>>> ​
>>> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:

 Dear all,

 I could use some help here, because I can't believe I'm not able to 
 easily print formatted numbers under Julia in a easy way. What I try to do 
 is to write a function that, given a vector, prints all its components 
 with 
 a user-defined format. I was trying something of the form

 function Print_Vec(aux_VEC,form_VEC)
 form_VEC :: ASCIIString
 str_VEC  = "%16.8f"
 for elem_VEC in aux_VEC
 str_VEC += @sprintf(form_VEC,elem_VEC)
 end
 return str_VEC
 end

 However, that doesn't work because it looks like the first argument in 
 @sprintf must be a explicit string, and not a variable.
 Is there anything I can do with that?

 Thanks a lot for your help.

>>>

[julia-users] Re: Tripping myself up on macro hygiene (again...)

[Tomas Lycken]

I ended up building the Expr explicitly, but I’d still like to know if this 
is the idiomatic way or if there’s another that’s considered “better”:

foo(N) = Expr(:call, :gradient, :A, map(k -> symbol("xs_", k), 1:N)...)

// T

On Tuesday, September 22, 2015 at 9:11:05 AM UTC+2, Tomas Lycken wrote:

I’m having real difficulties grok-ing macro hygiene. I’ve read the manual 
> entry, but didn’t get much wiser, so I’m hoping the solution to my current 
> problem will be another data point I can use to understand (and I need this 
> to work :P).
>
> I have a utility function that builds an expression (which will later be 
> interpolated into the method body of a generated function, but that’s out 
> of scope for my current problem), something like this:
>
> julia> using Base.Cartesian
>
> julia> foo(N) = :(gradient(A, (@ntuple $N k->xs_k)...))
> foo (generic function with 1 method)
>
> julia> macroexpand(foo(2))
> :(gradient(A,(xs_1,xs_2)...))
>
> Now, as you see, the generated tuple is splatted at run time. I’d like to 
> try to move that splatting to compile time, so that the generated 
> expression is rather :(gradient(A, xs_1, xs_2)). I’ve tried variants on 
> the following, but as you can see I haven’t had any success.
>
> I assume that I need to escape N somehow - but how?
>
> julia> foo(N) = :(gradient(A, $((@ntuple N k->xs_k)...)))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, ::Expr)
>
> julia> foo(N) = :(gradient(A, $((@ntuple $N k->xs_k)...)))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
>
> julia> foo(N) = :(gradient(A, $(esc((@ntuple N k->xs_k)...
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, ::Expr)
>
> julia> foo(N) = :(gradient(A, $(esc((@ntuple :N k->xs_k)...
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
>
> julia> foo(N) = :(gradient(A, $(@ntuple esc(N) k->xs_k)...))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
>
> julia> foo(N) = :(gradient(A, $(@ntuple esc(:N) k->xs_k)...))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
>
> ​
>
​

[julia-users] Re: @sprintf with a format string

[Ferran Mazzanti]

Thanks, that seems to work.
Still it amazes me how Julia, being a language made for numerical 
calculations, does not natively support a simple mechanism to print/write 
large bunches of numbers. I've been in the numerical world for 20+ years 
and I know printing lots of numbers is something you get on a daily
basis. I know now the formatting package can help on that (thanks :), what 
I do not like is the idea of having to install every time a new package
to get added functionality. I understand there are things that have to go 
to external packages because of its limited or specialized use, but
come on... printing number os definitely not one of those.
Just my 2cents :)

On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly wrote:
>
> https://github.com/JuliaLang/Formatting.jl might help.
>
> — Mike
> ​
> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:
>>
>> Dear all,
>>
>> I could use some help here, because I can't believe I'm not able to 
>> easily print formatted numbers under Julia in a easy way. What I try to do 
>> is to write a function that, given a vector, prints all its components with 
>> a user-defined format. I was trying something of the form
>>
>> function Print_Vec(aux_VEC,form_VEC)
>> form_VEC :: ASCIIString
>> str_VEC  = "%16.8f"
>> for elem_VEC in aux_VEC
>> str_VEC += @sprintf(form_VEC,elem_VEC)
>> end
>> return str_VEC
>> end
>>
>> However, that doesn't work because it looks like the first argument in 
>> @sprintf must be a explicit string, and not a variable.
>> Is there anything I can do with that?
>>
>> Thanks a lot for your help.
>>
>

[julia-users] Re: @sprintf with a format string

[Tomas Lycken]

Julia is a young language.

This comes with a lot of benefits - for example, it's possible to do things 
*right* from the start. We're currently in a phase where there is a 
multitude of possible solutions to every problem that arises, and we 
honestly don't know which solution proves to be the best one. Testing 
various solutions out in packages, outside of the base distribution, where 
they can compete for popularity, and keep building on top of each-other 
until we reach something which we believe not only is adequate, but 
*really* hits the sweet spot. In other words: sure, formatting numeric 
output is fundamental, but it's a problem with a large solution space, and 
we don't want to lock in on one path yet.

But Julia's young age also means that there are lots of problems that 
aren't really solved yet, or that have solutions proposed but not 
implemented, etc. For the future, there are plans to include some packages 
(which ones have not been decided, or AFAIK really even discussed) in a 
sort-of "base distribution", so they will be installed upon installation of 
Julia, and available with a single `using` statement. But the 
infrastructure for this is not in place yet, and even if it were, there 
would still be lots of reasons not to make a final decision on which 
packages make the cut until we approach a 1.0 release of the language.

So yeah, it might seem silly to have to install a package just to get 
fine-grained control of numeric output formatting, but, at least for now, 
that's part of what one could call Julia's "Package Deal" ;)

// T

On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti wrote:
>
> Thanks, that seems to work.
> Still it amazes me how Julia, being a language made for numerical 
> calculations, does not natively support a simple mechanism to print/write 
> large bunches of numbers. I've been in the numerical world for 20+ years 
> and I know printing lots of numbers is something you get on a daily
> basis. I know now the formatting package can help on that (thanks :), what 
> I do not like is the idea of having to install every time a new package
> to get added functionality. I understand there are things that have to go 
> to external packages because of its limited or specialized use, but
> come on... printing number os definitely not one of those.
> Just my 2cents :)
>
> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly wrote:
>>
>> https://github.com/JuliaLang/Formatting.jl might help.
>>
>> — Mike
>> ​
>> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:
>>>
>>> Dear all,
>>>
>>> I could use some help here, because I can't believe I'm not able to 
>>> easily print formatted numbers under Julia in a easy way. What I try to do 
>>> is to write a function that, given a vector, prints all its components with 
>>> a user-defined format. I was trying something of the form
>>>
>>> function Print_Vec(aux_VEC,form_VEC)
>>> form_VEC :: ASCIIString
>>> str_VEC  = "%16.8f"
>>> for elem_VEC in aux_VEC
>>> str_VEC += @sprintf(form_VEC,elem_VEC)
>>> end
>>> return str_VEC
>>> end
>>>
>>> However, that doesn't work because it looks like the first argument in 
>>> @sprintf must be a explicit string, and not a variable.
>>> Is there anything I can do with that?
>>>
>>> Thanks a lot for your help.
>>>
>>

Re: [julia-users] Tripping myself up on macro hygiene (again...)

[Tomas Lycken]

That's quite a lot cleaner than what I came up with, and keeps as much of 
the expression as possible in regular code-syntax. Thanks!

// T

On Tuesday, September 22, 2015 at 11:23:33 AM UTC+2, Tim Holy wrote:
>
> What you're trying isn't easy because the results of @ntuple, unless 
> contained 
> inside an Expr, will be eval'ed so you'll still create the tuple. And 
> expression-tuples are not iterable, so you can't splat them. 
>
> Manual construction: 
>
> function foo(N) 
> args = [symbol("xs_",k) for k = 1:N] 
> :(gradient(A, $(args...))) 
> end 
>
> The Cartesian package had an `@ncall`, but I found that I so often wanted 
> new 
> combinations of arguments that it wasn't worth it so didn't port it over 
> to 
> Base. 
>
> --Tim 
>
> On Tuesday, September 22, 2015 12:11:05 AM Tomas Lycken wrote: 
> > I’m having real difficulties grok-ing macro hygiene. I’ve read the 
> manual 
> > entry, but didn’t get much wiser, so I’m hoping the solution to my 
> current 
> > problem will be another data point I can use to understand (and I need 
> this 
> > to work :P). 
> > 
> > I have a utility function that builds an expression (which will later be 
> > interpolated into the method body of a generated function, but that’s 
> out 
> > of scope for my current problem), something like this: 
> > 
> > julia> using Base.Cartesian 
> > 
> > julia> foo(N) = :(gradient(A, (@ntuple $N k->xs_k)...)) 
> > foo (generic function with 1 method) 
> > 
> > julia> macroexpand(foo(2)) 
> > 
> > :(gradient(A,(xs_1,xs_2)...)) 
> > 
> > Now, as you see, the generated tuple is splatted at run time. I’d like 
> to 
> > try to move that splatting to compile time, so that the generated 
> > expression is rather :(gradient(A, xs_1, xs_2)). I’ve tried variants on 
> the 
> > following, but as you can see I haven’t had any success. 
> > 
> > I assume that I need to escape N somehow - but how? 
> > 
> > julia> foo(N) = :(gradient(A, $((@ntuple N k->xs_k)...))) 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, 
> > ::Expr) 
> > 
> > julia> foo(N) = :(gradient(A, $((@ntuple $N k->xs_k)...))) 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, 
> ::Expr) 
> > 
> > julia> foo(N) = :(gradient(A, $(esc((@ntuple N k->xs_k)... 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol, 
> > ::Expr) 
> > 
> > julia> foo(N) = :(gradient(A, $(esc((@ntuple :N k->xs_k)... 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, 
> ::Expr) 
> > 
> > julia> foo(N) = :(gradient(A, $(@ntuple esc(N) k->xs_k)...)) 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, 
> ::Expr) 
> > 
> > julia> foo(N) = :(gradient(A, $(@ntuple esc(:N) k->xs_k)...)) 
> > ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, 
> ::Expr) 
> > 
> > ​ 
>
>

Re: [julia-users] Tripping myself up on macro hygiene (again...)

[Tim Holy]

What you're trying isn't easy because the results of @ntuple, unless contained 
inside an Expr, will be eval'ed so you'll still create the tuple. And 
expression-tuples are not iterable, so you can't splat them.

Manual construction:

function foo(N)
args = [symbol("xs_",k) for k = 1:N]
:(gradient(A, $(args...)))
end

The Cartesian package had an `@ncall`, but I found that I so often wanted new 
combinations of arguments that it wasn't worth it so didn't port it over to 
Base.

--Tim

On Tuesday, September 22, 2015 12:11:05 AM Tomas Lycken wrote:
> I’m having real difficulties grok-ing macro hygiene. I’ve read the manual
> entry, but didn’t get much wiser, so I’m hoping the solution to my current
> problem will be another data point I can use to understand (and I need this
> to work :P).
> 
> I have a utility function that builds an expression (which will later be
> interpolated into the method body of a generated function, but that’s out
> of scope for my current problem), something like this:
> 
> julia> using Base.Cartesian
> 
> julia> foo(N) = :(gradient(A, (@ntuple $N k->xs_k)...))
> foo (generic function with 1 method)
> 
> julia> macroexpand(foo(2))
> 
> :(gradient(A,(xs_1,xs_2)...))
> 
> Now, as you see, the generated tuple is splatted at run time. I’d like to
> try to move that splatting to compile time, so that the generated
> expression is rather :(gradient(A, xs_1, xs_2)). I’ve tried variants on the
> following, but as you can see I haven’t had any success.
> 
> I assume that I need to escape N somehow - but how?
> 
> julia> foo(N) = :(gradient(A, $((@ntuple N k->xs_k)...)))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol,
> ::Expr)
> 
> julia> foo(N) = :(gradient(A, $((@ntuple $N k->xs_k)...)))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
> 
> julia> foo(N) = :(gradient(A, $(esc((@ntuple N k->xs_k)...
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Symbol,
> ::Expr)
> 
> julia> foo(N) = :(gradient(A, $(esc((@ntuple :N k->xs_k)...
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
> 
> julia> foo(N) = :(gradient(A, $(@ntuple esc(N) k->xs_k)...))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
> 
> julia> foo(N) = :(gradient(A, $(@ntuple esc(:N) k->xs_k)...))
> ERROR: MethodError: `_ntuple` has no method matching _ntuple(::Expr, ::Expr)
> 
> ​

[julia-users] Re: @sprintf with a format string

[Tomas Lycken]

> If C can have one, why can't Julia?

*The hard truth, and nothing but it:* If Julia is missing a feature, or has 
one that works in a way that's not the way you want, it's because no-one 
has wanted what you want enough to actually implement it.

That's it. There's no "it can't be done" - Julia is Turing complete, so 
"everything" can be done. There's no "it's not allowed" - no-one is 
stopping you from writing your own package, with your own implementation 
that does what you want the way you want it done, putting it in the package 
repository and seeing it take off. Chances are that if you write something 
that it turns out many others want as well, it will be included in the 
default package distribution in the future (or even in base Julia). Or it 
might not take off, but at least be there for your own enjoyment.

But the entire language, with all tooling, packages, etc - everything that 
is Julia - is very much a community-built product. Everything that is 
there, is there because someone at some point said *hey, this is so 
important to me that I'm going to put it at the very top of my priority 
list*. Creating a sprintf function that fulfills your needs might not have 
made it there for anyone yet. If it's that important to you, maybe that's 
your next contribution?

// T

On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:
>
> I might be wrong, but to me Formatting.jl looks next to useless. The 
> "sprintf" functions it provides only accept one parameter. The main 
> function provided is `sprintf1()`, but even the very clumsy 
> `generate_formatter()` function fails at the most basic tasks:
>
> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
> ERROR: Only one AND undecorated format string is allowed
>  in generate_formatter at 
> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>
>
> I really don't understand why sprintf() is such a big deal. If C can have 
> one, why can't Julia? I understand the argument that you might want to 
> rewrite the implementation later. Fine. Just call the function 
> "__temp_sprintf()" and put it in a package called 
> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
> print formatted strings without a ton of needless hassle.
>
>
>
> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>>
>> By the way, you might also note that the Formatting.jl package is written 
>> and maintained by people who are all active contributors to the main 
>> language repo, and very active members of the community. Even if it's 
>> "external" in terms of how you install it, it's by no means external "in 
>> spirit".
>>
>> // T
>>
>> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:
>>>
>>> Julia is a young language.
>>>
>>> This comes with a lot of benefits - for example, it's possible to do 
>>> things *right* from the start. We're currently in a phase where there is a 
>>> multitude of possible solutions to every problem that arises, and we 
>>> honestly don't know which solution proves to be the best one. Testing 
>>> various solutions out in packages, outside of the base distribution, where 
>>> they can compete for popularity, and keep building on top of each-other 
>>> until we reach something which we believe not only is adequate, but 
>>> *really* hits the sweet spot. In other words: sure, formatting numeric 
>>> output is fundamental, but it's a problem with a large solution space, and 
>>> we don't want to lock in on one path yet.
>>>
>>> But Julia's young age also means that there are lots of problems that 
>>> aren't really solved yet, or that have solutions proposed but not 
>>> implemented, etc. For the future, there are plans to include some packages 
>>> (which ones have not been decided, or AFAIK really even discussed) in a 
>>> sort-of "base distribution", so they will be installed upon installation of 
>>> Julia, and available with a single `using` statement. But the 
>>> infrastructure for this is not in place yet, and even if it were, there 
>>> would still be lots of reasons not to make a final decision on which 
>>> packages make the cut until we approach a 1.0 release of the language.
>>>
>>> So yeah, it might seem silly to have to install a package just to get 
>>> fine-grained control of numeric output formatting, but, at least for now, 
>>> that's part of what one could call Julia's "Package Deal" ;)
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti 
>>> wrote:

 Thanks, that seems to work.
 Still it amazes me how Julia, being a language made for numerical 
 calculations, does not natively support a simple mechanism to print/write 
 large bunches of numbers. I've been in the numerical world for 20+ 
 years and I know printing lots of numbers is something you get on a daily
 basis. I know now the formatting package can help on that (thanks :), 
 what I do not like is the idea of having to 

Re: [julia-users] linspace and HDF5

[Christoph Ortner]

Judging from your contributions to Julia you must have been the most 
sophisticated (in terms of coding ability) Matlab user ever :).

Christoph


On Tuesday, 22 September 2015 11:05:01 UTC+1, Tim Holy wrote:
>
> I'm a former Matlab user, and I hated meshgrid even before I discovered 
> Julia 
> :-). 
>
> --Tim 
>
> On Tuesday, September 22, 2015 03:01:08 AM Christoph Ortner wrote: 
> > Tempting, but logically it really shouldn't be in PyCall. (in my view) 
> > 
> > Also - it is not just PyPlot/PyCall lovers, but also former Matlab 
> users. 
> > 
> >   Christoph 
> > 
> > On Tuesday, 22 September 2015 10:47:23 UTC+1, Tim Holy wrote: 
> > > On Tuesday, September 22, 2015 02:37:55 AM Christoph Ortner wrote: 
> > > > another example why meshgrid should be in Base. :) 
> > > 
> > > Rightly or wrongly, I think I've noticed a correlation between "loves 
> > > meshgrid" and "uses PyPlot/PyCall". So why not just submit a PR to add 
> it 
> > > to 
> > > PyCall.jl? The power is in your hands :-). 
> > > 
> > > --Tim 
>
>

Re: [julia-users] linspace and HDF5

[Christoph Ortner]

P.S.: this means you don't count!

Judging from your contributions to Julia you must have been the most 
> sophisticated (in terms of coding ability) Matlab user ever :).
>
> Christoph
>
>>
>>

Re: [julia-users] linspace and HDF5

[Christoph Ortner]

Tempting, but logically it really shouldn't be in PyCall. (in my view)

Also - it is not just PyPlot/PyCall lovers, but also former Matlab users. 

  Christoph

On Tuesday, 22 September 2015 10:47:23 UTC+1, Tim Holy wrote:
>
> On Tuesday, September 22, 2015 02:37:55 AM Christoph Ortner wrote: 
> > another example why meshgrid should be in Base. :) 
>
> Rightly or wrongly, I think I've noticed a correlation between "loves 
> meshgrid" and "uses PyPlot/PyCall". So why not just submit a PR to add it 
> to 
> PyCall.jl? The power is in your hands :-). 
>
> --Tim 
>
>

Re: [julia-users] linspace and HDF5

[Tim Holy]

I'm a former Matlab user, and I hated meshgrid even before I discovered Julia 
:-).

--Tim

On Tuesday, September 22, 2015 03:01:08 AM Christoph Ortner wrote:
> Tempting, but logically it really shouldn't be in PyCall. (in my view)
> 
> Also - it is not just PyPlot/PyCall lovers, but also former Matlab users.
> 
>   Christoph
> 
> On Tuesday, 22 September 2015 10:47:23 UTC+1, Tim Holy wrote:
> > On Tuesday, September 22, 2015 02:37:55 AM Christoph Ortner wrote:
> > > another example why meshgrid should be in Base. :)
> > 
> > Rightly or wrongly, I think I've noticed a correlation between "loves
> > meshgrid" and "uses PyPlot/PyCall". So why not just submit a PR to add it
> > to
> > PyCall.jl? The power is in your hands :-).
> > 
> > --Tim

[julia-users] FFTW.REDFT00 and FFT.RODFT00 are ~10x slower than other routines?

[Sheehan Olver]

I get the following timings with the various FFTW routines, where I ran 
each line multiple times to make sure it was accurate.  Why are REDFT00 and 
RODFT00 almost 10x slower?


r=rand(10)
@time FFTW.r2r(r,FFTW.REDFT00) #0.26s
@time FFTW.r2r(r,FFTW.REDFT01) #0.0033s
@time FFTW.r2r(r,FFTW.REDFT10) #0.0035s
@time FFTW.r2r(r,FFTW.REDFT11) #0.0033s
@time FFTW.r2r(r,FFTW.RODFT00) #0.017s
@time FFTW.r2r(r,FFTW.RODFT01) #0.0035s
@time FFTW.r2r(r,FFTW.RODFT10) #0.0035s
@time FFTW.r2r(r,FFTW.RODFT11) #0.0035s
@time fft(r)   #0.0033s

[julia-users] Re: FFTW.REDFT00 and FFT.RODFT00 are ~10x slower than other routines?

[Sheehan Olver]

This is in 0.4rc2 on OS X.

On Tuesday, September 22, 2015 at 8:51:50 PM UTC+10, Sheehan Olver wrote:
>
> I get the following timings with the various FFTW routines, where I ran 
> each line multiple times to make sure it was accurate.  Why are REDFT00 and 
> RODFT00 almost 10x slower?
>
>
> r=rand(10)
> @time FFTW.r2r(r,FFTW.REDFT00) #0.26s
> @time FFTW.r2r(r,FFTW.REDFT01) #0.0033s
> @time FFTW.r2r(r,FFTW.REDFT10) #0.0035s
> @time FFTW.r2r(r,FFTW.REDFT11) #0.0033s
> @time FFTW.r2r(r,FFTW.RODFT00) #0.017s
> @time FFTW.r2r(r,FFTW.RODFT01) #0.0035s
> @time FFTW.r2r(r,FFTW.RODFT10) #0.0035s
> @time FFTW.r2r(r,FFTW.RODFT11) #0.0035s
> @time fft(r)   #0.0033s
>
>

[julia-users] Re: poisson distribution?

[Kristoffer Carlsson]

How slow is it? For me 100 million values take 5 seconds. The code just 
ccalls to the Rmath library to get the random number.

On Tuesday, September 22, 2015 at 11:51:19 AM UTC+2, Jon Norberg wrote:
>
> I need to get random variables from poisson distributions with different 
> lambda
>
> this is the only way I got it to work at the moment BUT its very slow!
>
> using Distributions
> lambda=linspace(0.1,2,100)
> out=zeros(Int64,100)
> for i=1:length(lambda)
>   P=Poisson(lambda[i])
>   out[i]=rand(P)
> end
>
> Anyone have suggestions for speed improvements?
>
> Thanks
>
>

Re: [julia-users] linspace and HDF5

[Tim Holy]

On Tuesday, September 22, 2015 02:37:55 AM Christoph Ortner wrote:
> another example why meshgrid should be in Base. :)

Rightly or wrongly, I think I've noticed a correlation between "loves 
meshgrid" and "uses PyPlot/PyCall". So why not just submit a PR to add it to 
PyCall.jl? The power is in your hands :-).

--Tim

Re: [julia-users] Is UInt for storing binary strings or unsigned integers?

[elextr]

There is a (very) small argument for unsigned array indexes in C/C++ where 
indexing is from zero, but as Stefan says, for Julia, with indexing 
starting at one, you have to test both limits anyway.

On Tuesday, September 22, 2015 at 1:11:03 AM UTC+10, Stefan Karpinski wrote:
>
> Suppose you have a situation where any UInt value is valid. Since only 
> valid values can be represented, this implies that you cannot validate 
> inputs at all – it's impossible to represent any invalid values. So you're 
> definitely not doing anything useful to catch or report errors.
>
> Suppose that non-negativity isn't the only criterion for validity. E.g. 
> array indices: only integral values from 1 to length(v) are valid. That 
> means you need to check bounds anyway, which means the UInt type doesn't 
> help at all since you still need to check that the UInt value is ≥ 1 and ≤ 
> length(v). In fact, using UInt mostly means that you can't easily tell if 
> you tried to use a value that is too large or too small – arithmetic 
> wrap-around means you'll almost always get values that are too large.
>
> Using unsigned integers for error checking is a bogus argument. They hide 
> errors rather than helping surface or debug them. If you index into an 
> array and you give an invalid index, you'll get a bounds error. Any type 
> you build on top of arrays will inherit this checking. If there are 
> additional constraints that your APIs have on valid inputs, they should 
> check them.
>
> On Mon, Sep 21, 2015 at 8:05 AM, Milan Bouchet-Valat  > wrote:
>
>> Le dimanche 20 septembre 2015 à 17:07 -0400, Jesse Johnson a écrit :
>> > In a thread about printing UInt variables, Milan Bouchet-Valat said:
>> > > The point is, in Julia using unsigned ints to store values that
>> > > should
>> > > always be positive is *not* recommended.
>> > If that is true, then shouldn't the type be called Byte? It seems the
>> > type has been misnamed if it was never intended to store unsigned
>> > integers.
>> >
>> > Further, calling the type UInt is misleading to devs from C lang
>> > family
>> > who frequently depend on compile-time type checking (ex. int vs.
>> > uint)
>> > to help ensure no unexpected signs show up. I am not suggesting
>> > type-checking is a perfect defense against sign errors, and thorough
>> > runtime testing is definitely necessary. In my larger projects
>> > combining
>> > type checking and runtime tests is almost a practical necessity and
>> > can
>> > seriously cut down on time spent bug hunting sign errors.
>> >
>> > That said, I am guessing the suggested solution in Julia is to rely
>> > solely on runtime sign checking? I can't see how I could make that
>> > practical for my use cases, but it would be good to know if that is
>> > what the Julia devs intend.
>> I think so. One of the references I could find is this:
>> https://groups.google.com/d/msg/julia-users/RX8sFQHvEV4/ttxfYufL7WUJ
>>
>>
>> Regards
>>
>
>

Re: [julia-users] linspace and HDF5

[Christoph Ortner]

another example why meshgrid should be in Base. :)
Christoph

[julia-users] poisson distribution?

[Jon Norberg]

I need to get random variables from poisson distributions with different 
lambda

this is the only way I got it to work at the moment BUT its very slow!

using Distributions
lambda=linspace(0.1,2,100)
out=zeros(Int64,100)
for i=1:length(lambda)
  P=Poisson(lambda[i])
  out[i]=rand(P)
end

Anyone have suggestions for speed improvements?

Thanks

Re: [julia-users] Re: @sprintf with a format string

[Daniel Carrera]

Coding sprintf() is beyond my skill, I tried. My contributions to Julia
have to lie elsewhere (recently I've been putting a lot of time making
mockups of a Julia IDE, and helping a new user port his Matlab code). I
think it is rude to say "if you don't like it, fix it yourself"; especially
after you wrote a post claiming that the non-implementation of sprintf()
was an intentional omission because developers weren't sure how to do it
right. I showed, correctly, that that argument is nonsense; so you spinned
around and changed it to "if you don't like it, fix it yourself". That
answer is only a way to reject valid complaints, and it feels like a thinly
veiled "fuck you". Imagine if that's how people responded in bug reports.
This is not the type of answer that Julia developers normally give, and it
is not the type of answer that I expect in Julia; especially after giving a
very different answer to the same question. I do try to contribute to
Julia, and it is rude and unreasonable to hold me personally responsible
for fixing everything that does not work in Julia. A healthy community
needs room for receiving legitimate complaints.

Daniel.

On 22 September 2015 at 15:49, Tomas Lycken  wrote:

> > If C can have one, why can't Julia?
>
> *The hard truth, and nothing but it:* If Julia is missing a feature, or
> has one that works in a way that's not the way you want, it's because
> no-one has wanted what you want enough to actually implement it.
>
> That's it. There's no "it can't be done" - Julia is Turing complete, so
> "everything" can be done. There's no "it's not allowed" - no-one is
> stopping you from writing your own package, with your own implementation
> that does what you want the way you want it done, putting it in the package
> repository and seeing it take off. Chances are that if you write something
> that it turns out many others want as well, it will be included in the
> default package distribution in the future (or even in base Julia). Or it
> might not take off, but at least be there for your own enjoyment.
>
> But the entire language, with all tooling, packages, etc - everything that
> is Julia - is very much a community-built product. Everything that is
> there, is there because someone at some point said *hey, this is so
> important to me that I'm going to put it at the very top of my priority
> list*. Creating a sprintf function that fulfills your needs might not
> have made it there for anyone yet. If it's that important to you, maybe
> that's your next contribution?
>
> // T
>
> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:
>>
>> I might be wrong, but to me Formatting.jl looks next to useless. The
>> "sprintf" functions it provides only accept one parameter. The main
>> function provided is `sprintf1()`, but even the very clumsy
>> `generate_formatter()` function fails at the most basic tasks:
>>
>> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
>> ERROR: Only one AND undecorated format string is allowed
>>  in generate_formatter at
>> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>>
>>
>> I really don't understand why sprintf() is such a big deal. If C can have
>> one, why can't Julia? I understand the argument that you might want to
>> rewrite the implementation later. Fine. Just call the function
>> "__temp_sprintf()" and put it in a package called
>> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to
>> print formatted strings without a ton of needless hassle.
>>
>>
>>
>> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>>>
>>> By the way, you might also note that the Formatting.jl package is
>>> written and maintained by people who are all active contributors to the
>>> main language repo, and very active members of the community. Even if it's
>>> "external" in terms of how you install it, it's by no means external "in
>>> spirit".
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:

 Julia is a young language.

 This comes with a lot of benefits - for example, it's possible to do
 things *right* from the start. We're currently in a phase where there is a
 multitude of possible solutions to every problem that arises, and we
 honestly don't know which solution proves to be the best one. Testing
 various solutions out in packages, outside of the base distribution, where
 they can compete for popularity, and keep building on top of each-other
 until we reach something which we believe not only is adequate, but
 *really* hits the sweet spot. In other words: sure, formatting numeric
 output is fundamental, but it's a problem with a large solution space, and
 we don't want to lock in on one path yet.

 But Julia's young age also means that there are lots of problems that
 aren't really solved yet, or that have solutions proposed but not
 implemented, etc. For the future, 

Re: [julia-users] Re: @sprintf with a format string

[Kristoffer Carlsson]

http://stackoverflow.com/questions/19783030/in-julia-why-is-printf-a-macro-instead-of-a-function

On Tuesday, September 22, 2015 at 4:20:41 PM UTC+2, Tom Breloff wrote:
>
> Chill guys.
>
> Anyways... I started to tackle this problem, but didn't get any (much 
> needed) comments on whether I was on the right track.  Here's some sample 
> preliminary usage of what I was working on.  Please let me know if you 
> think it's worth continuing, and what you'd ideally like to see in a 
> formatter.
>
> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>
> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  > wrote:
>
>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>> have to lie elsewhere (recently I've been putting a lot of time making 
>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>> after you wrote a post claiming that the non-implementation of sprintf() 
>> was an intentional omission because developers weren't sure how to do it 
>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>> around and changed it to "if you don't like it, fix it yourself". That 
>> answer is only a way to reject valid complaints, and it feels like a thinly 
>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>> This is not the type of answer that Julia developers normally give, and it 
>> is not the type of answer that I expect in Julia; especially after giving a 
>> very different answer to the same question. I do try to contribute to 
>> Julia, and it is rude and unreasonable to hold me personally responsible 
>> for fixing everything that does not work in Julia. A healthy community 
>> needs room for receiving legitimate complaints.
>>
>> Daniel.
>>
>> On 22 September 2015 at 15:49, Tomas Lycken > > wrote:
>>
>>> > If C can have one, why can't Julia?
>>>
>>> *The hard truth, and nothing but it:* If Julia is missing a feature, or 
>>> has one that works in a way that's not the way you want, it's because 
>>> no-one has wanted what you want enough to actually implement it.
>>>
>>> That's it. There's no "it can't be done" - Julia is Turing complete, so 
>>> "everything" can be done. There's no "it's not allowed" - no-one is 
>>> stopping you from writing your own package, with your own implementation 
>>> that does what you want the way you want it done, putting it in the package 
>>> repository and seeing it take off. Chances are that if you write something 
>>> that it turns out many others want as well, it will be included in the 
>>> default package distribution in the future (or even in base Julia). Or it 
>>> might not take off, but at least be there for your own enjoyment.
>>>
>>> But the entire language, with all tooling, packages, etc - everything 
>>> that is Julia - is very much a community-built product. Everything that is 
>>> there, is there because someone at some point said *hey, this is so 
>>> important to me that I'm going to put it at the very top of my priority 
>>> list*. Creating a sprintf function that fulfills your needs might not 
>>> have made it there for anyone yet. If it's that important to you, maybe 
>>> that's your next contribution?
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:

 I might be wrong, but to me Formatting.jl looks next to useless. The 
 "sprintf" functions it provides only accept one parameter. The main 
 function provided is `sprintf1()`, but even the very clumsy 
 `generate_formatter()` function fails at the most basic tasks:

 julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
 ERROR: Only one AND undecorated format string is allowed
  in generate_formatter at 
 /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23


 I really don't understand why sprintf() is such a big deal. If C can 
 have one, why can't Julia? I understand the argument that you might want 
 to 
 rewrite the implementation later. Fine. Just call the function 
 "__temp_sprintf()" and put it in a package called 
 "FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
 print formatted strings without a ton of needless hassle.



 On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>
> By the way, you might also note that the Formatting.jl package is 
> written and maintained by people who are all active contributors to the 
> main language repo, and very active members of the community. Even if 
> it's 
> "external" in terms of how you install it, it's by no means external "in 
> spirit".
>
> // T
>
> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken 
> wrote:
>>
>> Julia is a young language.
>>
>> This comes with a 

Re: [julia-users] Re: Can Julia function be serialized and sent by network?

[Andrei]

So far the best way to overcome it is to install all needed Julia packages
on every machine. This is not very convenient, but at least it's not a
blocker and you need to install some Julia packages manually anyway (though
I'm thinking of creating API for massive installation of packages on all
Spark workers).

I'm not sure what you mean by "Julia-on-C++", though.

On Tue, Sep 22, 2015 at 5:33 AM, edward zhang  wrote:

>
> hmm, I'm already very interested in the project like
> Julia-on-(Spark/c++?),
> and the ser/des issue is a big obstacle.
> 在 2015年9月21日星期一 UTC+8下午9:30:05，Andrei Zh写道：
>>
>> Hi,
>>
>> not yet. I made some initial research regarding serialization of ASTs and
>> reconstructing functions from them, but it seems quite a tricky procedure
>> and I have very little time for this project now. I plan to come back to
>> this issue around the beginning of the next month.
>>
>> On Mon, Sep 21, 2015 at 11:25 AM, edward zhang 
>> wrote:
>>
>>> hi， dear，
>>>  have you already fixed this problem？
>>>
>>>
>>> 在 2015年8月14日星期五 UTC+8下午11:06:30，Andrei Zh写道：
>>>

 Hi Jake,

 your example works because you don't leave Julia session. `foo` is
 defined in this session, so the the pair of module name and function name
 is enough to get function object. If you save serialized function (or just
 retype it byte by byte) , it won't work. Here's an example:

 Session #1:

 julia> io = IOBuffer()
 IOBuffer(data=Uint8[...], readable=true, writable=true, seekable=true,
 append=false, size=0, maxsize=Inf, ptr=1, mark=-1)


 julia> foo(x) =  x + 1
 foo (generic function with 1 method)


 julia> serialize(io, foo)


 julia> takebuf_array(io)
 9-element Array{Uint8,1}:
  0x13
  0x02
  0x23
  0x2f
  0x02
  0x03
  0x66
  0x6f
  0x6f


 julia>



 Session #2:

 julia> data = Uint8[0x13, 0x02, 0x23, 0x2f, 0x02, 0x03, 0x66, 0x6f,
 0x6f]
 9-element Array{Uint8,1}:
  0x13
  0x02
  0x23
  0x2f
  0x02
  0x03
  0x66
  0x6f
  0x6f


 julia> io = IOBuffer(data)
 IOBuffer(data=Uint8[...], readable=true, writable=false, seekable=true,
 append=false, size=9, maxsize=Inf, ptr=1, mark=-1)


 julia> bar = deserialize(io)
 (anonymous function)


 julia> bar(1)
 ERROR: function foo not defined on process 1
  in error at error.jl:21
  in anonymous at serialize.jl:398


 julia>








 On Friday, August 14, 2015 at 5:49:55 PM UTC+3, Jake Bolewski wrote:
>
> Andrei Zh
>
> I'm confused.  Have you actually tried?
>
> julia> io = IOBuffer()
> IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true,
> append=false, size=0, maxsize=Inf, ptr=1, mark=-1)
>
> julia> foo(x) =  x + 1
> foo (generic function with 1 method)
>
> julia> serialize(io, foo)
>
> julia> seekstart(io)
> IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true,
> append=false, size=9, maxsize=Inf, ptr=1, mark=-1)
>
> julia> baz = deserialize(io)
> foo (generic function with 1 method)
>
> julia> baz(1)
> 2
>
> The serialization code won't recursively serialize all the of the
> functions dependencies so you will have to send/serialize the code that
> defines the environment (types, constants, Packages, etc).
>

>>

[julia-users] Re: poisson distribution?

[Jon Norberg]

Sorry, thought I could delete threadso deleted first postmy bad

[julia-users] Re: What's your favourite editor?

[Andrei Zh]

>
> I'd be grateful to hear from other emacs users regarding your workflows 
> for Julia development, e.g. if you want to write a Julia package what emacs 
> packages, setup and workflow help you to be the most productive?
>
>
I use ESS + autocomplete + few keybindings (I'll post exact .init.el later 
when I get home), but there's one important thing about code organization 
that I worked out with time and now find very convenient. 

When developing a module, I put all the code in a file called "core.jl" 
 (or other files included into "core.jl"), and then in "MyModule.jl" simply 
write:

module MyModule
export ...


include("core.jl")


end



This allows to open "core.jl" in Emacs, load the file (C-c C-c) and work 
like "from inside" the module, i.e. reload any function, keep variables, 
types, etc. without the need to reload the whole module and thus reset all 
variables. 

[julia-users] Re: PyCall crash after running Pkg.update()

[jamesmnason]

Hi Steven:

Thanks.

I ran Pkg.update() this morning, using PyCall, and using PyPlot and Julia 
responded with no problems.

Whatever the problem was, seems to have disappeared into the virtual ether.

Jim 

On Monday, September 21, 2015 at 12:40:42 PM UTC-4, Steven G. Johnson wrote:
>
> I haven't seen that before.  The latest PyCall works fine (its tests are 
> passing) on the Travis Ubuntu machines and on my Debian box, both with 
> Python 2.7 and Python 3.x.
>
> On Monday, September 21, 2015 at 12:10:23 PM UTC-4, james...@gmail.com 
> wrote:
>>
>> Hi All:
>>
>> I run Pkg.update() in Julia v0.3.11 (under Xubuntu 14.04/x64).  
>>
>> When the update got to PyCall, the return was
>>
>>
>> INFO: PyCall is using python (Python 2.7.10) at 
>> /home/jim_nason/anaconda/bin/python, libpython = 
>> /home/jim_nason/anaconda/lib/libpython2.7.so
>>
>>
>> Yes, I recently updated conda and anaconda.
>>
>> Next, at the Julia command line, the command
>>
>> using PyCall
>>
>> returned 
>>
>> signal (11): Segmentation fault
>> unknown function (ip: 877497914)
>> unknown function (ip: 877498019)
>> jl_get_binding at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> jl_get_global at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> jl_module_run_initializer at 
>> /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown line)
>> unknown function (ip: 877387427)
>> unknown function (ip: 877386277)
>> unknown function (ip: 877388029)
>> jl_load at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown 
>> line)
>> include at ./boot.jl:245
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> include_from_node1 at ./loading.jl:128
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877321624)
>> unknown function (ip: 877317760)
>> unknown function (ip: 877385322)
>> jl_f_top_eval at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> reload_path at loading.jl:152
>> _require at loading.jl:67
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> require at loading.jl:54
>> jlcall_require_20813 at  (unknown line)
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877381117)
>> unknown function (ip: 877386083)
>> unknown function (ip: 877323877)
>> unknown function (ip: 877386366)
>> unknown function (ip: 877388029)
>> jl_load at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown 
>> line)
>> include at ./boot.jl:245
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> include_from_node1 at ./loading.jl:128
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877321624)
>> unknown function (ip: 877317760)
>> unknown function (ip: 877385322)
>> unknown function (ip: 877388029)
>> jl_load at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown 
>> line)
>> include at ./boot.jl:245
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> include_from_node1 at ./loading.jl:128
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877321624)
>> unknown function (ip: 877317760)
>> unknown function (ip: 877385322)
>> unknown function (ip: 877387086)
>> unknown function (ip: 877386277)
>> unknown function (ip: 877388029)
>> jl_load at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown 
>> line)
>> include at ./boot.jl:245
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> include_from_node1 at ./loading.jl:128
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877321624)
>> unknown function (ip: 877317760)
>> unknown function (ip: 877385322)
>> jl_f_top_eval at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> reload_path at loading.jl:152
>> _require at loading.jl:67
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> require at loading.jl:51
>> jlcall_require_20813 at  (unknown line)
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function (ip: 877381117)
>> unknown function (ip: 877385955)
>> jl_f_top_eval at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> eval_user_input at REPL.jl:53
>> jlcall_eval_user_input_20210 at  (unknown line)
>> jl_apply_generic at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> anonymous at task.jl:95
>> jl_handle_stack_switch at 
>> /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so (unknown line)
>> julia_trampoline at /usr/bin/../lib/x86_64-linux-gnu/julia/libjulia.so 
>> (unknown line)
>> unknown function 

[julia-users] Re: poisson distribution?

[Jon Norberg]

I think I had a problem in how I used the resulting data that slowed it 
down. 

Solved, Thanks

[julia-users] Re: When does colon indexing get evaluated / converted?

[Matt Bauman]

A colon by itself is simply a synonym for `Colon()`, both on 0.3 and 0.4:

julia> :
Colon()

You can use colons in normal function calls and dispatch in both 0.3 and 
0.4:

julia> f(x::Colon) = x
   f(:)
Colon()

That's what's happening with that sub definition.  `sub` acts like 
indexing, but it's just a normal function call.  And so the Colon() passes 
through unchanged in both 0.3 and 0.4.

Indexing expressions are different.  There are some special lowering steps 
to handle colon (just in 0.3) and end (in both 0.3 and 0.4).  "Lowering" is 
an intermediate step between parsing and compilation, and you can see what 
happens to an expression during lowering by calling `expand`.  The expanded 
expressions have some funny things in them (`top(endof)(A)` is a special 
internal pseudo-syntax that is kinda-sorta like saying `Base.endof(A)`), 
but you can see how the `end` keyword lowers to getindex calls in both 0.3 
and 0.4:

julia> expand(:(A[end]))
:(getindex(A,(top(endof))(A)))

julia> expand(:(A[1, end]))
:(getindex(A,1,(top(trailingsize))(A,2)))

julia> expand(:(A[1, end, 3]))
:(getindex(A,1,(top(size))(A,2),3))

So, now to the difference between 0.3 and 0.4: the special lowering step 
for colons in indexing expressions was removed.

# Julia 0.3:
julia> expand(:(A[:]))
:(getindex(A,colon(1,(top(endof))(A

# Julia 0.4:
julia> expand(:(A[:]))
:(getindex(A,:))

You can see that in 0.3, it effectively expanded to `1:end`.  But 0.4 just 
left the `:` symbol as it was, and it just gets evaluated normally as an 
argument to getindex.  It's no longer special. So in 0.4, you can 
specialize dispatch on Colon indices.

Make sense?

On Tuesday, September 22, 2015 at 1:07:01 AM UTC-4, Greg Plowman wrote:
>
> Hi All,
> Thanks all for your replies.
>
> OK I can see this will be much easier in v0.4.
> I will revisit when v0.4 released.
>
> I'm still curious about colon and end
>
>> Colon lowering changed in 0.4, 
>
>
> Matt, could you expand on this? How/when is this done in v0.3 vs v0.4?
>
> Does this mean v0.3 code attempting to dispatch on Colon type cannot 
> work? (for example the code from subarray.jl quoted below) 
>
> sub(A::AbstractArray, I::Union(RangeIndex, Colon)...) = sub(A, ntuple(
> length(I), i-> isa(I[i], Colon) ? (1:size(A,i)) : I[i])...)
>
> I noticed that  OffsetArrays (https://github.com/alsam/OffsetArrays.jl 
> 
>  
> jA 
> )
>  
> defines const (..) = Colon(), presumably to use .. in place of :
>
> Will it work in v0.4?
> How and when is end converted?
>
> Thanks again,
> Greg
>
>
>
>

[julia-users] Re: @sprintf with a format string

[Daniel Carrera]

I might be wrong, but to me Formatting.jl looks next to useless. The 
"sprintf" functions it provides only accept one parameter. The main 
function provided is `sprintf1()`, but even the very clumsy 
`generate_formatter()` function fails at the most basic tasks:

julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
ERROR: Only one AND undecorated format string is allowed
 in generate_formatter at 
/home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23


I really don't understand why sprintf() is such a big deal. If C can have 
one, why can't Julia? I understand the argument that you might want to 
rewrite the implementation later. Fine. Just call the function 
"__temp_sprintf()" and put it in a package called 
"FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
print formatted strings without a ton of needless hassle.



On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>
> By the way, you might also note that the Formatting.jl package is written 
> and maintained by people who are all active contributors to the main 
> language repo, and very active members of the community. Even if it's 
> "external" in terms of how you install it, it's by no means external "in 
> spirit".
>
> // T
>
> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:
>>
>> Julia is a young language.
>>
>> This comes with a lot of benefits - for example, it's possible to do 
>> things *right* from the start. We're currently in a phase where there is a 
>> multitude of possible solutions to every problem that arises, and we 
>> honestly don't know which solution proves to be the best one. Testing 
>> various solutions out in packages, outside of the base distribution, where 
>> they can compete for popularity, and keep building on top of each-other 
>> until we reach something which we believe not only is adequate, but 
>> *really* hits the sweet spot. In other words: sure, formatting numeric 
>> output is fundamental, but it's a problem with a large solution space, and 
>> we don't want to lock in on one path yet.
>>
>> But Julia's young age also means that there are lots of problems that 
>> aren't really solved yet, or that have solutions proposed but not 
>> implemented, etc. For the future, there are plans to include some packages 
>> (which ones have not been decided, or AFAIK really even discussed) in a 
>> sort-of "base distribution", so they will be installed upon installation of 
>> Julia, and available with a single `using` statement. But the 
>> infrastructure for this is not in place yet, and even if it were, there 
>> would still be lots of reasons not to make a final decision on which 
>> packages make the cut until we approach a 1.0 release of the language.
>>
>> So yeah, it might seem silly to have to install a package just to get 
>> fine-grained control of numeric output formatting, but, at least for now, 
>> that's part of what one could call Julia's "Package Deal" ;)
>>
>> // T
>>
>> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti wrote:
>>>
>>> Thanks, that seems to work.
>>> Still it amazes me how Julia, being a language made for numerical 
>>> calculations, does not natively support a simple mechanism to print/write 
>>> large bunches of numbers. I've been in the numerical world for 20+ years 
>>> and I know printing lots of numbers is something you get on a daily
>>> basis. I know now the formatting package can help on that (thanks :), 
>>> what I do not like is the idea of having to install every time a new package
>>> to get added functionality. I understand there are things that have to 
>>> go to external packages because of its limited or specialized use, but
>>> come on... printing number os definitely not one of those.
>>> Just my 2cents :)
>>>
>>> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly 
>>> wrote:

 https://github.com/JuliaLang/Formatting.jl might help.

 — Mike
 ​
 On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:
>
> Dear all,
>
> I could use some help here, because I can't believe I'm not able to 
> easily print formatted numbers under Julia in a easy way. What I try to 
> do 
> is to write a function that, given a vector, prints all its components 
> with 
> a user-defined format. I was trying something of the form
>
> function Print_Vec(aux_VEC,form_VEC)
> form_VEC :: ASCIIString
> str_VEC  = "%16.8f"
> for elem_VEC in aux_VEC
> str_VEC += @sprintf(form_VEC,elem_VEC)
> end
> return str_VEC
> end
>
> However, that doesn't work because it looks like the first argument in 
> @sprintf must be a explicit string, and not a variable.
> Is there anything I can do with that?
>
> Thanks a lot for your help.
>

Re: [julia-users] Re: @sprintf with a format string

[Tom Breloff]

Chill guys.

Anyways... I started to tackle this problem, but didn't get any (much
needed) comments on whether I was on the right track.  Here's some sample
preliminary usage of what I was working on.  Please let me know if you
think it's worth continuing, and what you'd ideally like to see in a
formatter.

https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl

On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  wrote:

> Coding sprintf() is beyond my skill, I tried. My contributions to Julia
> have to lie elsewhere (recently I've been putting a lot of time making
> mockups of a Julia IDE, and helping a new user port his Matlab code). I
> think it is rude to say "if you don't like it, fix it yourself"; especially
> after you wrote a post claiming that the non-implementation of sprintf()
> was an intentional omission because developers weren't sure how to do it
> right. I showed, correctly, that that argument is nonsense; so you spinned
> around and changed it to "if you don't like it, fix it yourself". That
> answer is only a way to reject valid complaints, and it feels like a thinly
> veiled "fuck you". Imagine if that's how people responded in bug reports.
> This is not the type of answer that Julia developers normally give, and it
> is not the type of answer that I expect in Julia; especially after giving a
> very different answer to the same question. I do try to contribute to
> Julia, and it is rude and unreasonable to hold me personally responsible
> for fixing everything that does not work in Julia. A healthy community
> needs room for receiving legitimate complaints.
>
> Daniel.
>
> On 22 September 2015 at 15:49, Tomas Lycken 
> wrote:
>
>> > If C can have one, why can't Julia?
>>
>> *The hard truth, and nothing but it:* If Julia is missing a feature, or
>> has one that works in a way that's not the way you want, it's because
>> no-one has wanted what you want enough to actually implement it.
>>
>> That's it. There's no "it can't be done" - Julia is Turing complete, so
>> "everything" can be done. There's no "it's not allowed" - no-one is
>> stopping you from writing your own package, with your own implementation
>> that does what you want the way you want it done, putting it in the package
>> repository and seeing it take off. Chances are that if you write something
>> that it turns out many others want as well, it will be included in the
>> default package distribution in the future (or even in base Julia). Or it
>> might not take off, but at least be there for your own enjoyment.
>>
>> But the entire language, with all tooling, packages, etc - everything
>> that is Julia - is very much a community-built product. Everything that is
>> there, is there because someone at some point said *hey, this is so
>> important to me that I'm going to put it at the very top of my priority
>> list*. Creating a sprintf function that fulfills your needs might not
>> have made it there for anyone yet. If it's that important to you, maybe
>> that's your next contribution?
>>
>> // T
>>
>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:
>>>
>>> I might be wrong, but to me Formatting.jl looks next to useless. The
>>> "sprintf" functions it provides only accept one parameter. The main
>>> function provided is `sprintf1()`, but even the very clumsy
>>> `generate_formatter()` function fails at the most basic tasks:
>>>
>>> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
>>> ERROR: Only one AND undecorated format string is allowed
>>>  in generate_formatter at
>>> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>>>
>>>
>>> I really don't understand why sprintf() is such a big deal. If C can
>>> have one, why can't Julia? I understand the argument that you might want to
>>> rewrite the implementation later. Fine. Just call the function
>>> "__temp_sprintf()" and put it in a package called
>>> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to
>>> print formatted strings without a ton of needless hassle.
>>>
>>>
>>>
>>> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:

 By the way, you might also note that the Formatting.jl package is
 written and maintained by people who are all active contributors to the
 main language repo, and very active members of the community. Even if it's
 "external" in terms of how you install it, it's by no means external "in
 spirit".

 // T

 On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken wrote:
>
> Julia is a young language.
>
> This comes with a lot of benefits - for example, it's possible to do
> things *right* from the start. We're currently in a phase where there is a
> multitude of possible solutions to every problem that arises, and we
> honestly don't know which solution proves to be the best one. Testing
> various solutions out in packages, outside of the base 

Re: [julia-users] Re: @sprintf with a format string

[Tomas Lycken]

If anything I wrote came off as a "thinly veiled 'fuck you'", I am 
sincerely sorry; that's nowhere near what I meant to say.

My two answers were directed at very different pieces of critique: first, I 
reacted to the statement "what I do not like is the idea of having to 
install every time a new package to get added functionality", explaining 
why this is actually a Good Thing for Julia at the moment, and was really 
quite unrelated to formatting.

Then, you replied that "Formatting.jl looks next to useless" and "I really 
don't understand why sprintf is such a big deal. If C can have one, why 
can't Julia?" I interpreted that, apparently wrongfully, as implying not 
only that you disliked the currently available implementations, but also 
that you thought it couldn't be so hard to do better, so my second answer 
had a different solution to the problem. (Note also that the two posts 
aren't directed at the same person.)

Re-reading the thread I think both our tones are harsher than necessary, 
and I apologize for my part in that.

// T

On Tuesday, September 22, 2015 at 4:20:41 PM UTC+2, Tom Breloff wrote:
>
> Chill guys.
>
> Anyways... I started to tackle this problem, but didn't get any (much 
> needed) comments on whether I was on the right track.  Here's some sample 
> preliminary usage of what I was working on.  Please let me know if you 
> think it's worth continuing, and what you'd ideally like to see in a 
> formatter.
>
> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>
> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  > wrote:
>
>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>> have to lie elsewhere (recently I've been putting a lot of time making 
>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>> after you wrote a post claiming that the non-implementation of sprintf() 
>> was an intentional omission because developers weren't sure how to do it 
>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>> around and changed it to "if you don't like it, fix it yourself". That 
>> answer is only a way to reject valid complaints, and it feels like a thinly 
>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>> This is not the type of answer that Julia developers normally give, and it 
>> is not the type of answer that I expect in Julia; especially after giving a 
>> very different answer to the same question. I do try to contribute to 
>> Julia, and it is rude and unreasonable to hold me personally responsible 
>> for fixing everything that does not work in Julia. A healthy community 
>> needs room for receiving legitimate complaints.
>>
>> Daniel.
>>
>> On 22 September 2015 at 15:49, Tomas Lycken > > wrote:
>>
>>> > If C can have one, why can't Julia?
>>>
>>> *The hard truth, and nothing but it:* If Julia is missing a feature, or 
>>> has one that works in a way that's not the way you want, it's because 
>>> no-one has wanted what you want enough to actually implement it.
>>>
>>> That's it. There's no "it can't be done" - Julia is Turing complete, so 
>>> "everything" can be done. There's no "it's not allowed" - no-one is 
>>> stopping you from writing your own package, with your own implementation 
>>> that does what you want the way you want it done, putting it in the package 
>>> repository and seeing it take off. Chances are that if you write something 
>>> that it turns out many others want as well, it will be included in the 
>>> default package distribution in the future (or even in base Julia). Or it 
>>> might not take off, but at least be there for your own enjoyment.
>>>
>>> But the entire language, with all tooling, packages, etc - everything 
>>> that is Julia - is very much a community-built product. Everything that is 
>>> there, is there because someone at some point said *hey, this is so 
>>> important to me that I'm going to put it at the very top of my priority 
>>> list*. Creating a sprintf function that fulfills your needs might not 
>>> have made it there for anyone yet. If it's that important to you, maybe 
>>> that's your next contribution?
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:

 I might be wrong, but to me Formatting.jl looks next to useless. The 
 "sprintf" functions it provides only accept one parameter. The main 
 function provided is `sprintf1()`, but even the very clumsy 
 `generate_formatter()` function fails at the most basic tasks:

 julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
 ERROR: Only one AND undecorated format string is allowed
  in generate_formatter at 
 /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23


 I really don't understand why sprintf() is such a big deal. If C can 
 

[julia-users] Creating custom METADATA

[Andrew Gibb]

I'm trying to follow the steps in the 0.4 Manual to create a custom 
METADATA.jl so that I can distribute packages around my organisation. If I 
clone JuliaLang/METADATA.jl.git into a local folder, then call Pkg.init() 
on that folder, I get the following:

INFO: Initializing package repository /Users/andrewg/.julia/v0.4
INFO: Package directory /Users/andrewg/.julia/v0.4 is already initialized.

And no META_BRANCH is created. Can anyone suggest what I'm doing wrong?

Thanks

Andy

Re: [julia-users] Re: @sprintf with a format string

[Michael Hatherly]

Anyways… I started to tackle this problem

As an interesting/entertaining hack you can “lift” the formatting string 
out of @printf with a staged function:

immutable Formatter{format} end

fmt(str) = Formatter{symbol(str)}()

@generated function printf{format}(io :: IO, :: Formatter{format}, args...)
xs = [:(args[$i]::$(args[i])) for i = 1:length(args)]
quote
$(Expr(:meta, :inline))
@inbounds $(Expr(:macrocall, symbol("@printf"), :io, string(format), 
xs...))
nothing
end
end

julia> printf(STDOUT, fmt("%f"), pi)

Though, of course, the normal warnings with relying heavily on @generated 
should be noted.
Performance and resulting code seems to be roughly the same as using @printf 
with
hard-coded formatting strings, and faster that what Formatting.jl is able 
to get.

and what you’d ideally like to see in a formatter.

http://www.gigamonkeys.com/book/a-few-format-recipes.html… but maybe that’s 
just me :)

— Mike
​
On Tuesday, 22 September 2015 16:20:41 UTC+2, Tom Breloff wrote:
>
> Chill guys.
>
> Anyways... I started to tackle this problem, but didn't get any (much 
> needed) comments on whether I was on the right track.  Here's some sample 
> preliminary usage of what I was working on.  Please let me know if you 
> think it's worth continuing, and what you'd ideally like to see in a 
> formatter.
>
> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>
> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera  > wrote:
>
>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>> have to lie elsewhere (recently I've been putting a lot of time making 
>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>> after you wrote a post claiming that the non-implementation of sprintf() 
>> was an intentional omission because developers weren't sure how to do it 
>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>> around and changed it to "if you don't like it, fix it yourself". That 
>> answer is only a way to reject valid complaints, and it feels like a thinly 
>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>> This is not the type of answer that Julia developers normally give, and it 
>> is not the type of answer that I expect in Julia; especially after giving a 
>> very different answer to the same question. I do try to contribute to 
>> Julia, and it is rude and unreasonable to hold me personally responsible 
>> for fixing everything that does not work in Julia. A healthy community 
>> needs room for receiving legitimate complaints.
>>
>> Daniel.
>>
>> On 22 September 2015 at 15:49, Tomas Lycken > > wrote:
>>
>>> > If C can have one, why can't Julia?
>>>
>>> *The hard truth, and nothing but it:* If Julia is missing a feature, or 
>>> has one that works in a way that's not the way you want, it's because 
>>> no-one has wanted what you want enough to actually implement it.
>>>
>>> That's it. There's no "it can't be done" - Julia is Turing complete, so 
>>> "everything" can be done. There's no "it's not allowed" - no-one is 
>>> stopping you from writing your own package, with your own implementation 
>>> that does what you want the way you want it done, putting it in the package 
>>> repository and seeing it take off. Chances are that if you write something 
>>> that it turns out many others want as well, it will be included in the 
>>> default package distribution in the future (or even in base Julia). Or it 
>>> might not take off, but at least be there for your own enjoyment.
>>>
>>> But the entire language, with all tooling, packages, etc - everything 
>>> that is Julia - is very much a community-built product. Everything that is 
>>> there, is there because someone at some point said *hey, this is so 
>>> important to me that I'm going to put it at the very top of my priority 
>>> list*. Creating a sprintf function that fulfills your needs might not 
>>> have made it there for anyone yet. If it's that important to you, maybe 
>>> that's your next contribution?
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:

 I might be wrong, but to me Formatting.jl looks next to useless. The 
 "sprintf" functions it provides only accept one parameter. The main 
 function provided is `sprintf1()`, but even the very clumsy 
 `generate_formatter()` function fails at the most basic tasks:

 julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
 ERROR: Only one AND undecorated format string is allowed
  in generate_formatter at 
 /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23


 I really don't understand why sprintf() is such a big deal. If C can 
 have one, why can't Julia? I understand the argument that you might want 
 to 
 rewrite 

[julia-users] Re: FFTW.REDFT00 and FFT.RODFT00 are ~10x slower than other routines?

[Páll Haraldsson]

I'm just curious so I looked into it. I'm just, familiar, with what FFT, 
DCT, IDCT and Fourier transform is for.. but not really that much and my 
math is fading..

I got similar numbers (I'm on 0.3.11) to you and then I tried with (as I 
recall power of twos are what you should be using):

r=rand(2^20)

Then numbers are much more closer, but still a gap.


You can look at the code and edit! with edit(FFTW.r2r)

I'm not sure the former or latter numbers, are NOT what should be expected 
(or at least that a slowdown is introduced by Julia).

See here:
http://www.fftw.org/doc/1d-Real_002deven-DFTs-_0028DCTs_0029.html

That is the (GPL) library that does the heavy lifting (not coded in Julia), 
and there are the equations behind what you are doing.


You could do something like @profile FFTW.r2r(r,FFTW.REDFT00)

And look into how the profiler works (to see the results), but I doubt 
you'll see much interesting if it only shows the Julia side..


By just scanning the code I code like this:

execute(precision::fftwTypeDouble, plan) =
ccall((:fftw_execute,libfftw), Void, (Ptr{Void},), plan)

That I assume does all the work (e.g. the FFTW library that it calls).

-- 
Palli.

On Tuesday, September 22, 2015 at 10:52:10 AM UTC, Sheehan Olver wrote:
>
> This is in 0.4rc2 on OS X.
>
> On Tuesday, September 22, 2015 at 8:51:50 PM UTC+10, Sheehan Olver wrote:
>>
>> I get the following timings with the various FFTW routines, where I ran 
>> each line multiple times to make sure it was accurate.  Why are REDFT00 and 
>> RODFT00 almost 10x slower?
>>
>>
>> r=rand(10)
>> @time FFTW.r2r(r,FFTW.REDFT00) #0.26s
>> @time FFTW.r2r(r,FFTW.REDFT01) #0.0033s
>> @time FFTW.r2r(r,FFTW.REDFT10) #0.0035s
>> @time FFTW.r2r(r,FFTW.REDFT11) #0.0033s
>> @time FFTW.r2r(r,FFTW.RODFT00) #0.017s
>> @time FFTW.r2r(r,FFTW.RODFT01) #0.0035s
>> @time FFTW.r2r(r,FFTW.RODFT10) #0.0035s
>> @time FFTW.r2r(r,FFTW.RODFT11) #0.0035s
>> @time fft(r)   #0.0033s
>>
>>

Re: [julia-users] Why does type inference not work for cat? (0.4-rc1)

[Mauro]

After looking into this, I think this may be tricky to avoid.  But yes,
possibly a bug or certainly a feature to improve on.

One of the culprits is the following expression inside the cat function:

[isa(x,AbstractArray) ? eltype(x) : typeof(x) for x in X]

Checking this:

f2(X...) = [isa(x,AbstractArray) ? eltype(x) : typeof(x) for x in X]
Base.code_warntype(f2, Base.typesof(Any[1,1:5]...)) #  
Array{Union{Type{Int64},Type{UnitRange{Int64}}},1}

I tried to get around this with something like:

tmp(x::AbstractArray) = eltype(x)
tmp{T}(x::T) = T
function cat2(catdims, X...)
T = promote_type([tmp(x) for x in X]...)
cat_t(catdims, T, X...)
end

but that is not type-stable either, even though
`f(X...) = [tmp(x) for x in X]` is.
So digging deeper I came up with these tests:

xx = Any[1:5, 1]
TT = Type{Int64}[Int64, Int64] # isa Array{Type{Int64},1)
TT2 = [Int64, Int64]# isa Array{DataType,1)
TT3 = Any[Int64, Int64] # isa Array{DataType,1)
Base.code_warntype(promote_type, Base.typesof(TT...))  # works: Type{Int64}
Base.code_warntype(promote_type, Base.typesof(TT2...)) # works: Type{Int64}
Base.code_warntype(promote_type, Base.typesof(TT3...)) # works: Type{Int64}

# But using promote_type inside a function does not work:
p(x) = promote_type(x...)
@code_warntype p(TT) # Type{T}
# splatting seems to be the culprit:
p2(x) = promote_type(x[1],x[2])
@code_warntype p2(TT)

So it seems that using promote_type inside other functions is easily
type unstable. I would think this could be solved?

PS: Note that `@code_warntype` fails with splatting, thus the function
invocation above (https://github.com/JuliaLang/julia/issues/13264).

On Tue, 2015-09-22 at 02:26, Sheehan Olver  wrote:
> The code below can't infer the return type of cat.  Should I file an issue
> or is this expected?
>
>
> v=rand(5)
> @code_warntype cat(1,0.0,v,0.0)
> ...
> end::ANY

Re: [julia-users] Is UInt for storing binary strings or unsigned integers?

[Páll Haraldsson]

Yes and no(?). If array indexes are shifted by one and unsigned is used 
then you only need to compare to length(v)-1.

This subtract by one, is faster than compare in CPUs (usually..), besides 
the bounds checking isn't really a problem unless you are in a loop and 
then can't this just be done once? I'm assuming the optimizer is allowed to 
move stuff like this around.. Something a Java JVM would not be allowed to 
do (maybe JavaScript as you have the source code, not just byte code)?

That I'm not sure about, is if you can actually move the length(v) out of 
the loop and caching the result as arrays can grow (and then even move..). 
That would be bad, but in the common case would not happen., Jut the 
compiler would have to prove that, e.g. that the general case with that 
possibility does not apply..

-- 
Palli. 

On Tuesday, September 22, 2015 at 11:48:45 AM UTC, ele...@gmail.com wrote:
>
> There is a (very) small argument for unsigned array indexes in C/C++ where 
> indexing is from zero, but as Stefan says, for Julia, with indexing 
> starting at one, you have to test both limits anyway.
>
> On Tuesday, September 22, 2015 at 1:11:03 AM UTC+10, Stefan Karpinski 
> wrote:
>>
>> Suppose you have a situation where any UInt value is valid. Since only 
>> valid values can be represented, this implies that you cannot validate 
>> inputs at all – it's impossible to represent any invalid values. So you're 
>> definitely not doing anything useful to catch or report errors.
>>
>> Suppose that non-negativity isn't the only criterion for validity. E.g. 
>> array indices: only integral values from 1 to length(v) are valid. That 
>> means you need to check bounds anyway, which means the UInt type doesn't 
>> help at all since you still need to check that the UInt value is ≥ 1 and ≤ 
>> length(v). In fact, using UInt mostly means that you can't easily tell if 
>> you tried to use a value that is too large or too small – arithmetic 
>> wrap-around means you'll almost always get values that are too large.
>>
>> Using unsigned integers for error checking is a bogus argument. They hide 
>> errors rather than helping surface or debug them. If you index into an 
>> array and you give an invalid index, you'll get a bounds error. Any type 
>> you build on top of arrays will inherit this checking. If there are 
>> additional constraints that your APIs have on valid inputs, they should 
>> check them.
>>
>> On Mon, Sep 21, 2015 at 8:05 AM, Milan Bouchet-Valat  
>> wrote:
>>
>>> Le dimanche 20 septembre 2015 à 17:07 -0400, Jesse Johnson a écrit :
>>> > In a thread about printing UInt variables, Milan Bouchet-Valat said:
>>> > > The point is, in Julia using unsigned ints to store values that
>>> > > should
>>> > > always be positive is *not* recommended.
>>> > If that is true, then shouldn't the type be called Byte? It seems the
>>> > type has been misnamed if it was never intended to store unsigned
>>> > integers.
>>> >
>>> > Further, calling the type UInt is misleading to devs from C lang
>>> > family
>>> > who frequently depend on compile-time type checking (ex. int vs.
>>> > uint)
>>> > to help ensure no unexpected signs show up. I am not suggesting
>>> > type-checking is a perfect defense against sign errors, and thorough
>>> > runtime testing is definitely necessary. In my larger projects
>>> > combining
>>> > type checking and runtime tests is almost a practical necessity and
>>> > can
>>> > seriously cut down on time spent bug hunting sign errors.
>>> >
>>> > That said, I am guessing the suggested solution in Julia is to rely
>>> > solely on runtime sign checking? I can't see how I could make that
>>> > practical for my use cases, but it would be good to know if that is
>>> > what the Julia devs intend.
>>> I think so. One of the references I could find is this:
>>> https://groups.google.com/d/msg/julia-users/RX8sFQHvEV4/ttxfYufL7WUJ
>>>
>>>
>>> Regards
>>>
>>
>>

Re: [julia-users] Re: @sprintf with a format string

[Stefan Karpinski]

Responding with a solicitation for help in an open source project is not a
rhetorical ploy – it's a legitimate request for contribution. I wrote the
printf code in Julia some time ago and it clearly could use revisiting –
the API is not working out for people. However, that is a large amount of
design work and a tricky, performance-sensitive problem in generic
programming (Julia's has to support printing an open-ended set of types,
not just the limited set C has). Since I currently have a few other things
to worry about, one of the most effective ways to see that work done is to
do it yourself. Barring that, you just have to wait until someone does this
work.

A lecture on the importance of printing numbers is also not helpful and
pretty irritating. Yes, printing things is important, especially numbers.
Everyone is well aware, myself included – that's why I spent a month
implementing our generic printf in the first place. It will get fixed.

In the mean time, several viable solutions have been provided (repeatedly),
including...

1. *Use eval.* This lets you generate formatter functions for specific
runtime format strings:

julia> const fmt = "%05d %-5s %5.2f\n"
"%05d %-5s %5.2f\n"

julia> @eval formatter(i, s, x) = @printf($fmt, i, s, x)
formatter (generic function with 1 method)

julia> formatter(123, "flux", pi)
00123 flux   3.14


If you don't need to change the format in response to data, this is a fine
way to do things.

2. *Use Formatting.jl.* If you don't care for the interface, help improve
it. Help could take the form of pull requests, of just polite issues opened
to suggest how the interface could be enhanced. Calling it "next to
useless" and dismissing out of hand is rude and not particularly
constructive.

3. *Use C's printf.* Since this seems to be what you want and you can
easily call C from Julia, what's stopping you?

julia> ccall(:printf, Cint,
 (Cstring, Cint, Cstring, Cdouble),
 "%05d %-5s %5.2f\n", 123, "flux", pi)
00123 flux   3.14
18


It's not the most convenient interface in the world, but a little wrapping
would solve that. (It may also be incorrect since printf is a varargs
function – I was a little surprised that it worked – but using vprintf
would address that.)

On Tue, Sep 22, 2015 at 10:38 AM, Tomas Lycken 
wrote:

> If anything I wrote came off as a "thinly veiled 'fuck you'", I am
> sincerely sorry; that's nowhere near what I meant to say.
>
> My two answers were directed at very different pieces of critique: first,
> I reacted to the statement "what I do not like is the idea of having to
> install every time a new package to get added functionality", explaining
> why this is actually a Good Thing for Julia at the moment, and was really
> quite unrelated to formatting.
>
> Then, you replied that "Formatting.jl looks next to useless" and "I really
> don't understand why sprintf is such a big deal. If C can have one, why
> can't Julia?" I interpreted that, apparently wrongfully, as implying not
> only that you disliked the currently available implementations, but also
> that you thought it couldn't be so hard to do better, so my second answer
> had a different solution to the problem. (Note also that the two posts
> aren't directed at the same person.)
>
> Re-reading the thread I think both our tones are harsher than necessary,
> and I apologize for my part in that.
>
> // T
>
> On Tuesday, September 22, 2015 at 4:20:41 PM UTC+2, Tom Breloff wrote:
>>
>> Chill guys.
>>
>> Anyways... I started to tackle this problem, but didn't get any (much
>> needed) comments on whether I was on the right track.  Here's some sample
>> preliminary usage of what I was working on.  Please let me know if you
>> think it's worth continuing, and what you'd ideally like to see in a
>> formatter.
>>
>> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>>
>> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera 
>> wrote:
>>
>>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia
>>> have to lie elsewhere (recently I've been putting a lot of time making
>>> mockups of a Julia IDE, and helping a new user port his Matlab code). I
>>> think it is rude to say "if you don't like it, fix it yourself"; especially
>>> after you wrote a post claiming that the non-implementation of sprintf()
>>> was an intentional omission because developers weren't sure how to do it
>>> right. I showed, correctly, that that argument is nonsense; so you spinned
>>> around and changed it to "if you don't like it, fix it yourself". That
>>> answer is only a way to reject valid complaints, and it feels like a thinly
>>> veiled "fuck you". Imagine if that's how people responded in bug reports.
>>> This is not the type of answer that Julia developers normally give, and it
>>> is not the type of answer that I expect in Julia; especially after giving a
>>> very different answer to the same question. I do try to contribute to
>>>