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.lyc...@gmail.com> 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. >>>>>>> >>>>>>
