did you see the format function in the last part of Formatting.jl's readme?
On Sunday, September 27, 2015 at 3:00:23 PM UTC-4, Scott Jones wrote:
>
> I'm sorry - I meant to test it out right after you submitted the PR, I
> *do* think you are on the right track,
> but I've been caught up in the fun of writing code for my happy Belgian
> company (luckily, it's in Julia),
> and we hadn't gotten to the point where we needed nice formatting yet.
>
> I've since been thinking about having a string macro, that would have a
> simple syntax for calling your
> fmt function (and probably some other goodies):
> Something like:
> v1 = 10.23
> v2 = 1234567
> fmt_default!(Int, :commas, width = 12)
> println(f"This is a test of formatting <\{v1,3,7}> <\{v2}>")
> would print:
> This is a test of formatting < 10.230> < 1,234,567>
>
> So that essentially, \{...} is simply a shortcut that acts like
> $(fmt(...)).
>
> On Tuesday, September 22, 2015 at 10:20:41 AM UTC-4, 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 <[email protected]>
>> 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 <[email protected]> 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.
>>>>>>>>>>
>>>>>>>>>
>>>
>>
