If you're willing to make updates to your own code---and possibly contribute fixes to packages you depend on---I highly recommend migrating. In my hands, it's more stable & predictable than julia 0.3 despite 0.3's long history.
--Tim On Wednesday, September 23, 2015 01:14:33 PM Daniel Carrera wrote: > This implementation requires Julia 0.4. I use Julia in production work, and > 0.4 is in RC2. Is it safe to migrate or should I just wait? > > Cheers, > Daniel. > > On 23 September 2015 at 03:34, Tim Holy <[email protected]> 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.000004 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 <[email protected] > > > > > > > > <javascript:>> wrote: > > > >> On 22 September 2015 at 20:40, Stefan Karpinski <[email protected] > > > >> > > > >> <javascript:>> 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.
