If anything I wrote came off as a "thinly veiled 'fuck you'", I am sincerely sorry; that's nowhere near what I meant to say.
My two answers were directed at very different pieces of critique: first, I reacted to the statement "what I do not like is the idea of having to install every time a new package to get added functionality", explaining why this is actually a Good Thing for Julia at the moment, and was really quite unrelated to formatting. Then, you replied that "Formatting.jl looks next to useless" and "I really don't understand why sprintf is such a big deal. If C can have one, why can't Julia?" I interpreted that, apparently wrongfully, as implying not only that you disliked the currently available implementations, but also that you thought it couldn't be so hard to do better, so my second answer had a different solution to the problem. (Note also that the two posts aren't directed at the same person.) Re-reading the thread I think both our tones are harsher than necessary, and I apologize for my part in that. // T On Tuesday, September 22, 2015 at 4:20:41 PM 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. >>>>>>>>> >>>>>>>> >> >
