At this point it's safe to switch to 0.4-rc2 with one important condition: when 0.4 comes out, switch to it as soon as you can. There *can* be incompatibilities between release candidates and releases, so if you linger too long on a candidate, you can find yourself a bit stuck later on when you want to upgrade to get a bug fix.
On Wed, Sep 23, 2015 at 7:51 AM, Tomas Lycken <[email protected]> wrote: > 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]> 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. >>> >>> >> >
