May this lazy-good-for-nothing request a link?
Of course, https://groups.google.com/forum/#!msg/julia-users/hBbEGEopi0A/fKQcqDEVBgAJ. Took me a while to actually find it again myself… Implementation-wise they were pretty similar. I was dispatching of an instance Formatter{...}() rather than the FormatString{...} type itself, though the resulting generated code is identical as far as I can tell. — Mike On Wednesday, 23 September 2015 17:30:13 UTC+2, Tim Holy wrote: > > Actually, I looked back for what you wrote and didn't find it---even > search > (probably badly) julia-users on Google Groups. May this > lazy-good-for-nothing > request a link? > > --Tim > > On Wednesday, September 23, 2015 08:04:44 AM Michael Hatherly wrote: > > But Michael Hatherly’s showed code above that uses a generated function > to > > solve this. > > > > What am I missing? > > > > It’s probably because the thread was getting quite long and what I wrote > > simply got missed. > > > > — Mike > > > > > > On Wednesday, 23 September 2015 03:15:23 UTC+2, Bob Nnamtrop wrote: > > > 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 <[email protected] > > > > > > <javascript:>> 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 <[email protected] > > >> > > >> <javascript:>> 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 <[email protected]> > > > >>>> > > >>>> wrote: > > >>>>> On 22 September 2015 at 20:40, Stefan Karpinski < > [email protected]> > > >>>>> > > >>>>> 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/ec999b8e5ede67f42759657beb8c5fef8 > > >>>>>> 7c8cc63:/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. > >
