That depends on what you do in your “production work” ;)
0.4 RC2 is good enough that it would become 0.4 if no serious bugs or regressions are found. There’s currently one issue tagged with milestone 0.4.0 <https://github.com/JuliaLang/julia/milestones/0.4.0>, and another one tagged backport pending 0.4 <https://github.com/julialang/julia/issues?q=is%3Aopen+is%3Aissue+label%3A%22backport+pending+0.4%22>, and I don’t know if there are other places you should look to find things that need to be fixed before the RC cycle is considered finished, but I guess there’s at least going to be an RC3 too. It’s very possible that, for the areas of 0.4 that you would use, nothing will change between now and the final release. It’s also very possible that 0.4 is unusable to you in its current state - it depends entirely on your specific needs. But I would encourage you to try it out - there’s nothing that says you have to uninstall 0.3.11 yet :) // T PS: I have tried to learn macros, but I still think they are basically black magic. No matter what Julia concept we speak of, I could re-phrase that and apply it to myself, as I think I have a pretty good understanding of [Concept X], but in the hands of Tim Holy it is still black magic… On Wednesday, September 23, 2015 at 1:14:38 PM UTC+2, 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] <javascript:>> > 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. >> >> >
