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 <t...@breloff.com
> >
> > <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 <lstag...@gmail.com
> >>
> >> <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 <dcar...@gmail.com>
> >>>>
> >>>> wrote:
> >>>>> On 22 September 2015 at 20:40, Stefan Karpinski <ste...@karpinski.org>
> >>>>>
> >>>>> 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.
