Anyways… I started to tackle this problem

As an interesting/entertaining hack you can “lift” the formatting string 
out of @printf with a staged function:

immutable Formatter{format} end

fmt(str) = Formatter{symbol(str)}()

@generated function printf{format}(io :: IO, :: Formatter{format}, args...)
    xs = [:(args[$i]::$(args[i])) for i = 1:length(args)]
    quote
        $(Expr(:meta, :inline))
        @inbounds $(Expr(:macrocall, symbol("@printf"), :io, string(format), 
xs...))
        nothing
    end
end

julia> printf(STDOUT, fmt("%f"), pi)

Though, of course, the normal warnings with relying heavily on @generated 
should be noted.
Performance and resulting code seems to be roughly the same as using @printf 
with
hard-coded formatting strings, and faster that what Formatting.jl is able 
to get.

and what you’d ideally like to see in a formatter.

http://www.gigamonkeys.com/book/a-few-format-recipes.html… but maybe that’s 
just me :)

— Mike
​
On Tuesday, 22 September 2015 16:20:41 UTC+2, Tom Breloff wrote:
>
> Chill guys.
>
> Anyways... I started to tackle this problem, but didn't get any (much 
> needed) comments on whether I was on the right track.  Here's some sample 
> preliminary usage of what I was working on.  Please let me know if you 
> think it's worth continuing, and what you'd ideally like to see in a 
> formatter.
>
> https://github.com/tbreloff/Formatting.jl/blob/tom-fmt/test/fmt.jl
>
> On Tue, Sep 22, 2015 at 10:05 AM, Daniel Carrera <dcar...@gmail.com 
> <javascript:>> wrote:
>
>> Coding sprintf() is beyond my skill, I tried. My contributions to Julia 
>> have to lie elsewhere (recently I've been putting a lot of time making 
>> mockups of a Julia IDE, and helping a new user port his Matlab code). I 
>> think it is rude to say "if you don't like it, fix it yourself"; especially 
>> after you wrote a post claiming that the non-implementation of sprintf() 
>> was an intentional omission because developers weren't sure how to do it 
>> right. I showed, correctly, that that argument is nonsense; so you spinned 
>> around and changed it to "if you don't like it, fix it yourself". That 
>> answer is only a way to reject valid complaints, and it feels like a thinly 
>> veiled "fuck you". Imagine if that's how people responded in bug reports. 
>> This is not the type of answer that Julia developers normally give, and it 
>> is not the type of answer that I expect in Julia; especially after giving a 
>> very different answer to the same question. I do try to contribute to 
>> Julia, and it is rude and unreasonable to hold me personally responsible 
>> for fixing everything that does not work in Julia. A healthy community 
>> needs room for receiving legitimate complaints.
>>
>> Daniel.
>>
>> On 22 September 2015 at 15:49, Tomas Lycken <tomas....@gmail.com 
>> <javascript:>> wrote:
>>
>>> > If C can have one, why can't Julia?
>>>
>>> *The hard truth, and nothing but it:* If Julia is missing a feature, or 
>>> has one that works in a way that's not the way you want, it's because 
>>> no-one has wanted what you want enough to actually implement it.
>>>
>>> That's it. There's no "it can't be done" - Julia is Turing complete, so 
>>> "everything" can be done. There's no "it's not allowed" - no-one is 
>>> stopping you from writing your own package, with your own implementation 
>>> that does what you want the way you want it done, putting it in the package 
>>> repository and seeing it take off. Chances are that if you write something 
>>> that it turns out many others want as well, it will be included in the 
>>> default package distribution in the future (or even in base Julia). Or it 
>>> might not take off, but at least be there for your own enjoyment.
>>>
>>> But the entire language, with all tooling, packages, etc - everything 
>>> that is Julia - is very much a community-built product. Everything that is 
>>> there, is there because someone at some point said *hey, this is so 
>>> important to me that I'm going to put it at the very top of my priority 
>>> list*. Creating a sprintf function that fulfills your needs might not 
>>> have made it there for anyone yet. If it's that important to you, maybe 
>>> that's your next contribution?
>>>
>>> // T
>>>
>>> On Tuesday, September 22, 2015 at 3:17:55 PM UTC+2, Daniel Carrera wrote:
>>>>
>>>> I might be wrong, but to me Formatting.jl looks next to useless. The 
>>>> "sprintf" functions it provides only accept one parameter. The main 
>>>> function provided is `sprintf1()`, but even the very clumsy 
>>>> `generate_formatter()` function fails at the most basic tasks:
>>>>
>>>> julia> fmtrfunc = generate_formatter( "%10.3f   %6d  %3d" )
>>>> ERROR: Only one AND undecorated format string is allowed
>>>>  in generate_formatter at 
>>>> /home/daniel/.julia/v0.3/Formatting/src/cformat.jl:23
>>>>
>>>>
>>>> I really don't understand why sprintf() is such a big deal. If C can 
>>>> have one, why can't Julia? I understand the argument that you might want 
>>>> to 
>>>> rewrite the implementation later. Fine. Just call the function 
>>>> "__temp_sprintf()" and put it in a package called 
>>>> "FunctionThatWillGoAwayLater". I don't care. I just want to be able to 
>>>> print formatted strings without a ton of needless hassle.
>>>>
>>>>
>>>>
>>>> On Tuesday, 22 September 2015 10:03:52 UTC+2, Tomas Lycken wrote:
>>>>>
>>>>> By the way, you might also note that the Formatting.jl package is 
>>>>> written and maintained by people who are all active contributors to the 
>>>>> main language repo, and very active members of the community. Even if 
>>>>> it's 
>>>>> "external" in terms of how you install it, it's by no means external "in 
>>>>> spirit".
>>>>>
>>>>> // T
>>>>>
>>>>> On Tuesday, September 22, 2015 at 10:01:24 AM UTC+2, Tomas Lycken 
>>>>> wrote:
>>>>>>
>>>>>> Julia is a young language.
>>>>>>
>>>>>> This comes with a lot of benefits - for example, it's possible to do 
>>>>>> things *right* from the start. We're currently in a phase where there is 
>>>>>> a 
>>>>>> multitude of possible solutions to every problem that arises, and we 
>>>>>> honestly don't know which solution proves to be the best one. Testing 
>>>>>> various solutions out in packages, outside of the base distribution, 
>>>>>> where 
>>>>>> they can compete for popularity, and keep building on top of each-other 
>>>>>> until we reach something which we believe not only is adequate, but 
>>>>>> *really* hits the sweet spot. In other words: sure, formatting numeric 
>>>>>> output is fundamental, but it's a problem with a large solution space, 
>>>>>> and 
>>>>>> we don't want to lock in on one path yet.
>>>>>>
>>>>>> But Julia's young age also means that there are lots of problems that 
>>>>>> aren't really solved yet, or that have solutions proposed but not 
>>>>>> implemented, etc. For the future, there are plans to include some 
>>>>>> packages 
>>>>>> (which ones have not been decided, or AFAIK really even discussed) in a 
>>>>>> sort-of "base distribution", so they will be installed upon installation 
>>>>>> of 
>>>>>> Julia, and available with a single `using` statement. But the 
>>>>>> infrastructure for this is not in place yet, and even if it were, there 
>>>>>> would still be lots of reasons not to make a final decision on which 
>>>>>> packages make the cut until we approach a 1.0 release of the language.
>>>>>>
>>>>>> So yeah, it might seem silly to have to install a package just to get 
>>>>>> fine-grained control of numeric output formatting, but, at least for 
>>>>>> now, 
>>>>>> that's part of what one could call Julia's "Package Deal" ;)
>>>>>>
>>>>>> // T
>>>>>>
>>>>>> On Tuesday, September 22, 2015 at 9:43:05 AM UTC+2, Ferran Mazzanti 
>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks, that seems to work.
>>>>>>> Still it amazes me how Julia, being a language made for numerical 
>>>>>>> calculations, does not natively support a simple mechanism to 
>>>>>>> print/write 
>>>>>>> large bunches of numbers. I've been in the numerical world for 20+ 
>>>>>>> years and I know printing lots of numbers is something you get on a 
>>>>>>> daily
>>>>>>> basis. I know now the formatting package can help on that (thanks 
>>>>>>> :), what I do not like is the idea of having to install every time a 
>>>>>>> new 
>>>>>>> package
>>>>>>> to get added functionality. I understand there are things that have 
>>>>>>> to go to external packages because of its limited or specialized use, 
>>>>>>> but
>>>>>>> come on... printing number os definitely not one of those.
>>>>>>> Just my 2cents :)
>>>>>>>
>>>>>>> On Monday, September 21, 2015 at 10:52:52 AM UTC+2, Michael Hatherly 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> https://github.com/JuliaLang/Formatting.jl might help.
>>>>>>>>
>>>>>>>> — Mike
>>>>>>>> ​
>>>>>>>> On Monday, 21 September 2015 10:46:31 UTC+2, Ferran Mazzanti wrote:
>>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I could use some help here, because I can't believe I'm not able 
>>>>>>>>> to easily print formatted numbers under Julia in a easy way. What I 
>>>>>>>>> try to 
>>>>>>>>> do is to write a function that, given a vector, prints all its 
>>>>>>>>> components 
>>>>>>>>> with a user-defined format. I was trying something of the form
>>>>>>>>>
>>>>>>>>> function Print_Vec(aux_VEC,form_VEC)
>>>>>>>>>     form_VEC :: ASCIIString
>>>>>>>>>     str_VEC  = "%16.8f"
>>>>>>>>>     for elem_VEC in aux_VEC
>>>>>>>>>         str_VEC += @sprintf(form_VEC,elem_VEC)
>>>>>>>>>     end
>>>>>>>>>     return str_VEC
>>>>>>>>> end
>>>>>>>>>
>>>>>>>>> However, that doesn't work because it looks like the first 
>>>>>>>>> argument in @sprintf must be a explicit string, and not a variable.
>>>>>>>>> Is there anything I can do with that?
>>>>>>>>>
>>>>>>>>> Thanks a lot for your help.
>>>>>>>>>
>>>>>>>>
>>
>

Reply via email to