easbarbosa has quit [Remote host closed the connection]
ur5us has joined #ruby
jetchisel has joined #ruby
weaksauce has quit [Ping timeout: 268 seconds]
pusewicz has joined #ruby
<nakilon>
there should be a gemspec field thread_safe
<nakilon>
so people would see it on rubygems.org immediately when deciding to use and how to use the gem
FastJack has quit [Ping timeout: 268 seconds]
royo25 has joined #ruby
ur5us has quit [Ping timeout: 250 seconds]
TomyWork has joined #ruby
Danishman has joined #ruby
_aeris_ has quit [Ping timeout: 244 seconds]
lunarkitty has quit [Quit: Connection closed for inactivity]
_aeris_ has joined #ruby
Guest33 has joined #ruby
pusewicz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lunarkitty has joined #ruby
<adam12>
Most people probably don't know. Ie. See Samuel's talk about threads and fibers.
<ccooke>
I think I'v always worked on the assumption that any gem is not thread safe
<nakilon>
adam12 don't know if their gem is thread-safe? that's why I as their gem user should know if they don't know it
<adam12>
nakilon: Not sure how that helps tho. People would just set it to true even if they didn't know.
<nakilon>
I mean, just having this standard field in gemspec will make them start thinking about thread safety and if they don't know about it they won't set this field since it would be by default set to "not safe"
<nakilon>
most of fields in gemspec are optional -- people don't set them if they don't need to, I assume
<adam12>
nakilon: flat_map.compact isnt' just two method calls, it's two iterations through the collection. O(n)*2 or something.
<nakilon>
O(n)*2 = O(n) though
<jhass[m]>
O notation is not sufficient to point out all performance problems there are :)
<nakilon>
unfortunately there is no notation to point out problems of having bloated stdlib
<jhass[m]>
for really big collections it makes a difference. For many small collections it makes a difference if your forget to use .compact! over compact
<jhass[m]>
the latter due to GC pressure mostly
<nakilon>
the "want the return value of the block and not the element, when using something like Enumerator#find" isn't even a self-sufficient problem -- it's somewhere inside your algorithm where you might not even need to compact, it all depends on the whole picture
Guest33 has joined #ruby
<jhass[m]>
I'm actually responsible for Crystal having Enumerable#min_of/max_of which are min_by/max_by but returning the block's value. Not sure why "find_value" didn't happen at the same time
Guest33 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<riceandbeans>
I actually figured out a different way for my situation that was a little weird but it worked
<riceandbeans>
I'm validating it right now..
<riceandbeans>
But, so far in a quick test it seemed to work
<riceandbeans>
Basically, I flipped it. I added something than said bar.include(foo)
<riceandbeans>
So, if I get this test to exit 1, it will have worked, because I slipped in a broken file that should trigger it to exit badly where it exited cleanly before