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/ec999b8e5ede67f42759657beb8c5fef87c8cc63:/stdio-common/vfprintf.c>. This code is neither easy nor trivial – it's batsh*t crazy. 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. 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.
On Tue, Sep 22, 2015 at 1:22 PM, Daniel Carrera <dcarr...@gmail.com> wrote: > > On 22 September 2015 at 17:42, Stefan Karpinski <ste...@karpinski.org> > wrote: > >> Responding with a solicitation for help in an open source project is not >> a rhetorical ploy – it's a legitimate request for contribution. >> > > It can be either. It depends on context and intent. I have seen that > comment used both ways. I once saw a seminar that suggested that as a > technique to get rid of people you don't want to deal with (e.g. because > the person is disruptive in some way). > > > A lecture on the importance of printing numbers is also not helpful and >> pretty irritating. Yes, printing things is important, especially numbers. >> Everyone is well aware, myself included – that's why I spent a month >> implementing our generic printf in the first place. It will get fixed. >> > > > I don't know if this is a response to me or someone else. I never gave a > lecture on the importance of printing numbers. At least, I never intended > to and I don't know what I said that would come across like that. > > Anyway, I appreciate that you are busy with probably more important > things, and I thank you for the work you have already done. My email was > harsher than it should have been, but I was replying comments from Tomas. I > was not trying to file a complaint with the Julia devs. I know that you > know about the @sprintf() issue, and I was not trying to remind you of it. > I took issue with Tomas saying that printf() was not implemented because > the devs were trying to decide what the right implementation should be. I > don't think that this is, or should be, the right reason to not implement > printf(). I suspected that the real reason was, as you said, that there is > more work on your planet than just printf(). > > > > >> In the mean time, several viable solutions have been provided >> (repeatedly), including... >> > > I was not aware of the eval() option, but I was aware of the others. In > particular, I spent a while experimenting with C's printf() function, but I > was not able to make a generic wrapper around it. This means that, for me, > a direct call to C's printf is no more useful than the existing @sprintf > macro. I also compared Formatter.jl with @sprintf and I decided that > @sprintf served me better. > > > >> 2. *Use Formatting.jl.* If you don't care for the interface, help >> improve it. Help could take the form of pull requests, of just polite >> issues opened to suggest how the interface could be enhanced. Calling it >> "next >> to useless" and dismissing out of hand is rude and not particularly >> constructive. >> > > I was rude and I apologize. I don't think that Formatting.jl can be fixed. > I think that there is probably a good reason it only provides sprintf1(). I > don't think it would be news to the developers that a sprintf() that takes > more than one parameter is desirable. If they haven't done it, it is > because they can't. > > > >> 3. *Use C's printf.* Since this seems to be what you want and you can >> easily call C from Julia, what's stopping you? >> >> julia> ccall(:printf, Cint, >> (Cstring, Cint, Cstring, Cdouble), >> "%05d %-5s %5.2f\n", 123, "flux", pi) >> 00123 flux 3.14 >> 18 >> >> >> It's not the most convenient interface in the world, but a little >> wrapping would solve that. (It may also be incorrect since printf is a >> varargs function – I was a little surprised that it worked – but using >> vprintf would address that.) >> > > Yes, this is the approach I tried to work on. I was trying to make a > wrapper. But I was unable to make a generic one. Similar to the @eval > option, you end up having to make a wrapper for the specific format you > want to print. This means that, in the end, I am better off just writing > very long lines with @sprintf. > > Anyway, I again apologize for my harsh tone, I hope I have clarified some > of my thoughts, I hope I have re-assured you that I did look at the > alternatives, and I thank you for your work in Julia. > > Daniel. >
