<headius[m]> What's up kingram
<headius[m]> ilikeorangutans irb does have a different way of running code that might explain it
<headius[m]> I'll have a look tomorrow
xardion has quit [Ping timeout: 248 seconds]
him3010 has joined #jruby
rusk has joined #jruby
rusk has quit [Ping timeout: 268 seconds]
rusk has joined #jruby
lopex has quit [Ping timeout: 245 seconds]
lopex has joined #jruby
him3010 has quit [Ping timeout: 258 seconds]
Liothen has quit [Ping timeout: 250 seconds]
Liothen has joined #jruby
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
kares_ has joined #jruby
kares has quit [Ping timeout: 244 seconds]
kares_ is now known as kares
enebo has quit [Ping timeout: 258 seconds]
enebo has joined #jruby
shellac has joined #jruby
KeyJoo has joined #jruby
ilikeorangutans has joined #jruby
shellac has quit [Ping timeout: 252 seconds]
<ilikeorangutans> great, thanks headius!
xardion has joined #jruby
KeyJoo has quit [Quit: KeyJoo]
ilikeorangutans has quit [Ping timeout: 268 seconds]
ilikeorangutans has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
<ilikeorangutans> so... i think i found something else that doesn't work right on lazy enumerators. on mri ruby, when using an infinte enumerator, this returns 3 elements and stops:
<ilikeorangutans> enumerator.lazy.each_with_index.map { |x, i| x }.take(3).to_a
<ilikeorangutans> on jruby each_with_index tries to consume all elements
<ilikeorangutans> but if i run without each_with_index, it works just as expected
<ilikeorangutans> can someone confirm that what i'm seeing?
<ilikeorangutans> interestingly enough with_index works just as expected
<lopex> and what about each_cons and the like ?
<ilikeorangutans> haven't tested those; just stumbled over the issue with each_with_index because i was using it
<ilikeorangutans> quick test shows each_cons seems fine
<ilikeorangutans> in general there's something very funky with lazy enumerators:
<ilikeorangutans> a = [[1, 2], [2, 3]]
<ilikeorangutans> a.lazy.map { |x| x}.to_a
<ilikeorangutans> on mri returns: => [[1], [2]]
<ilikeorangutans> as you would expec .map { |x| x } to be the identity function
<ilikeorangutans> on jruby though:
<ilikeorangutans> irb(main):006:0> a.lazy.map { |x| x}.to_a
<ilikeorangutans> => [[[1]], [[2]]]
<ilikeorangutans> actually, it does that without lazy too
<ilikeorangutans> i'm very confused
<ilikeorangutans> no, disregard my last two messages. without lazy it works as expected
<ilikeorangutans> ok; lazy enumerator doesn't like single element arrays, it rewraps them into another array (tested on jruby 9.2.6.0)
<lopex> ah, it wuld explain since those are special opetimized cases
<lopex> *would
<ilikeorangutans> let me see
<lopex> one and two are specialized
<lopex> that would explain 1 and 2 lengths
<lopex> actually, it could explaint sigle array discrepancy too
<ilikeorangutans> could that explain the flat_map issue i've seen earlier this week?
<lopex> I've got bitten but those too in the past
<lopex> no idea
<lopex> yeah, I remember
<lopex> but no idea
<ilikeorangutans> in any case, i'm not crazy... haha there is something off here, right?
<lopex> you cold step through jruby code though
<lopex> there might be
<ilikeorangutans> i feel like identity function should work just work
<lopex> those opts are to save additional java array allocations for small ruby arrays
<ilikeorangutans> i was looking at flat_map, but i feel like i'm in over my head :(
<lopex> but they require extra plumbing in some places
<ilikeorangutans> i'll definitely open an issue on github to record my findings
<ilikeorangutans> oooh great find, let me try that
<ilikeorangutans> in the meantime, anything i should add to https://github.com/jruby/jruby/issues/5745 ?
<lopex> yeah, you could mention packed arrays as a suspect I guess
<lopex> possible one
<ilikeorangutans> yeah, will do; just testing that right now
<lopex> ilikeorangutans: https://github.com/jruby/jruby/wiki/PerformanceTuning tells how to change those options
<lopex> the other thing I see is callEach used in flatMapCommon
<lopex> whereas collectCommon( uses callEach19
<ilikeorangutans> I'd pass this option to jruby via -X packed.arrays=false, right?
<lopex> according to https://github.com/jruby/jruby/wiki/PerformanceTuning it's -J-Dkey=value
<ilikeorangutans> yeah, doesn't seem to have an impact
<lopex> er, I meant -D-Jjruby-packed.arrays=false
<lopex> er
<lopex> er, I meant -D-Jjruby.packed.arrays=false
<lopex> rather
<ilikeorangutans> you can check the value like so (just learned this): jruby -Xpacked\?
<ilikeorangutans> will output: packed.arrays=true
<ilikeorangutans> and you can disable it like so:
<ilikeorangutans> jruby -Xpacked.arrays=false -Xpacked\?
<ilikeorangutans> packed.arrays=false
<lopex> jruby --properties | grep packed
<ilikeorangutans> that one doesn't work for me: -> % jruby -D-Jjruby.packed.arrays=false
<ilikeorangutans> jruby: unknown option -D-Jjruby.packed.arrays=false
<ilikeorangutans> but -X seems to do the trick
* ilikeorangutans shrugs
<lopex> ah you're right
<lopex> jruby -Xpacked.arrays=false -e "p [[1], [2]].lazy.map { |x| x}.to_a"
<ilikeorangutans> in any case, thanks for your help, lopex!
<ilikeorangutans> i feel already a lot less mad now that someone is confirming what i'm seeing haha
<lopex> I'll try some thing though
<lopex> *things
<lopex> that callEach seems suspicious
<lopex> no, that's not that, since it goes enumeratorizeWithSize
<lopex> yeah, lazy or borked
<lopex> s/or/is/
<ilikeorangutans> :(
<lopex> it's all fiber magic I know nothing about
<lopex> or at least lazy/enumerator goes bad
ilikeorangutans has quit [Ping timeout: 258 seconds]
ebarrett has joined #jruby
cheald[m] has joined #jruby