<asterite>
About your other questions, I suggest to create github issues to discuss them (like the restriction on splats). Here it’s hard to follow, specially if there are many topics at the same time
<asterite>
Plus, it gets kind of lost in time
<asterite>
sferik: not that I didn’t want you to implement Iterator/Enumerator, it’s just that I had it already but we never pushed it because @waj wants to do something like what C# does with yield return (but I think that’s a lot of work, and maybe it’s not that hard to write iterators manually)
<kostya_>
for me this 7.5 times slower
<asterite>
kostya: with times.map ?
<kostya_>
yes
<asterite>
Really? Compiled with release?
<asterite>
That’s very, very strange
<kostya_>
crystal array_new_vs_int_times_map.cr --release user system total real Array#new 0.000290 0.000015 0.000305 ( 0.136604) times#map 0.001404 0.000519 0.001923 ( 1.015741)
<asterite>
Hmm… I tried it in a linux vm and for me it’s 5.3 times slower
<asterite>
I wonder if it depends on some llvm optimizations for that platform
<asterite>
Very strange
<asterite>
In any case it’ll always be slower than Array#new :(
<asterite>
I’d really like to try this in Rust, see if they somehow managed to make both methods have the same efficiency
<asterite>
(but I don’t know if there’s an Array#new with block equivalent in Rust)
<sferik>
asterite: thanks for looking into this
<asterite>
kostya: if you do that benchmark in Ruby, what are the timings?
<sferik>
asterite: I’d encourage you to publish some of these Gists as blog posts
<sferik>
asterite: and discuss why Crystal has chosen not to implement some of these methods yet
<sferik>
asterite: I think it's very good for the project to say, "we could implement this but we have decided not to, for this and this reason"
<sferik>
asterite: or "we've decided to implement it differently, for this and this reason"
<sferik>
asterite: otherwise, people may assume it's missing because you haven't had time to implement it yet
<sferik>
asterite: what do you think about each_slice vs. in_groups_of vs. in_groups?
<asterite>
They are useful, it’d be good to have them
<sferik>
asterite: all three of them?
<asterite>
Maybe each_slice could be confused with the Slice class
<sferik>
asterite: right, I think I made that point yesterday
<asterite>
But… Slice is used at the very low level, so most people won’t know about it
<sferik>
asterite: okay
<asterite>
so I don’t mind naming it each_slice
<sferik>
asterite: alternatively, I could just implement in_groups_of
<asterite>
They are the same?
<sferik>
asterite: which does basically the same thing as each_slide
<sferik>
*each_slice
<sferik>
asterite: very similar
<asterite>
The difference seems to be the “fill_with”, right?
<asterite>
I think right now you can do the same in Crystal, kind of, iterating the tuple or the array and checking types at runtime (the check will probably be gone because the compiler knows the types)
<asterite>
Sorry, gotta work now :)
<asterite>
But please create an issue if you want to discuss this further (we are very open to enhancements and changes)
<sferik>
asterite: I'm writing it up now
<sferik>
asterite: thanks for your feedback
<asterite>
Thank you :)
asterite has quit [Quit: asterite]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #crystal-lang
asterite has joined #crystal-lang
asterite has quit [Client Quit]
shama has joined #crystal-lang
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #crystal-lang
kostya_ has quit [Remote host closed the connection]
aritheory has quit [Ping timeout: 264 seconds]
sferik has quit [Read error: Connection reset by peer]
sferik_ has joined #crystal-lang
sferik_ has quit [Read error: Connection reset by peer]
sferik has joined #crystal-lang
travis-ci has joined #crystal-lang
<travis-ci>
manastech/crystal#1705 (master - b2f6acf : Ary Borenszweig): The build was broken.