The original PR: https://github.com/JuliaLang/Formatting.jl/pull/10 The tests (which show some basic usage): https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
In addition to this, we could have a `@fmt` macro which is analogous to `@show`, but uses fmt instead. Also, I think some helper methods would be good. An example: @withfmt width=20 align=right begin <do lots of printing> end # resets format spec The naming and API can be changed, but I want people to weigh in on the concept of per-type global formatting defaults. This will likely not be as performant as the @printf macro, but it should be fast enough for most uses. On Wed, Sep 23, 2015 at 11:39 AM, Tim Holy <[email protected]> wrote: > The size of the method cache is definitely something to consider. An > advantage > of the current @(s)printf, when the format string is known explicitly, is > that > it works at the call site and doesn't add to the cache. > > And yes, I like your proposal quite a lot. I don't have any personal > experience with Formatting.jl, but together with your macro it looks quite > powerful. > > Best, > --Tim > > On Wednesday, September 23, 2015 10:28:21 AM Tom Breloff wrote: > > Tim: I love that you just whipped up a generated function for this (one > > great thing about Julia is how many different ways you can tackle a > > problem), however do you see this type of solution as being better than > > Formatting's sprintf1? I would be worried about the sheer number of > > compiled versions (one for each format string, plus the macro expansion), > > but maybe that's not as much overhead as I think it is? > > > > Also I still think there's room for something like my `fmt` proposal, > which > > would allow for global defaults for formatting using the type hierarchy. > > The proposal is not meant to replace printf, but to supplement it. > > Sometimes you want to control how individual types are printed globally, > > without using a format string repeatedly. In my proposal, you could set > > global fixed widths and precision (and other stuff) to both concrete and > > abstract types, and would allow for bonuses like nested calls within > > array/dataframe printing (potentially solving this type of problem: > > https://groups.google.com/forum/?hl=en#!topic/julia-users/S1aBoT9mQ_Y) > > > > If anyone thinks this is useful, please tell me. If you think it sucks, > > please tell me why. > > > > 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. > > >> > > >> > >
