<GitHub103>
jruby/master 1a635c5 Thomas E. Enebo: Fixes #4728. Parser does not seem to terminate when parsing this string.
nowhereFast has joined #jruby
<nowhereFast>
I'm trying to use the RxJava lib with JRuby which allows the use of a convenience method when converting an array over to an observable: Observable.from_iterable([1,2,3]). I figured great.. this should surely work in cases where I make use of a include Enumerable or a hash but it breaks with: undefined method `iterator'
<nowhereFast>
not sure if this is a JRuby or RxJava question.. -but can anyone tell me why it works for arrays but not for other enumerables?
<headius>
yo yo yo
<headius>
nowhereFast: that's likely because RubyArray, the Java class that implements Array, itself is a List and implements the iterable method
<nowhereFast>
wassup! :-)
<headius>
other Ruby types that just mix Enumerable in may or may not have that method as far as Java is concerned
<nowhereFast>
headius, would there be a straight forward way of letting the Java class know that List it is?
<headius>
if you make the Ruby type you're interested in implement the Java Iterable interface I think it will work fine
<nowhereFast>
I could go the Observable.create route, but they seem to advise against it and prefer using convenience methods
<nowhereFast>
ahh.. okay, I'll try that out
swills has quit [Remote host closed the connection]
swills has joined #jruby
swills has joined #jruby
swills has quit [Remote host closed the connection]
vtunka has quit [Quit: Leaving]
swills has joined #jruby
swills has quit [Changing host]
swills has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1 has quit [Remote host closed the connection]
anaeem1_ has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1 has quit [Remote host closed the connection]
anaeem1_ has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1 has quit [Remote host closed the connection]
<GitHub85>
[jruby] enebo created jruby-9.1.13.0 from 9.1.12.0 (+0 new commits): https://git.io/v7id5
<GitHub86>
[jruby] enebo pushed 1 new commit to jruby-9.1.13.0: https://git.io/v7idA
<GitHub86>
jruby/jruby-9.1.13.0 c59be67 Thomas E. Enebo: Fixes #4728. Parser does not seem to terminate when parsing this string.
<kares>
Q: seems that +/-/<</>> etc do not use the 'optimized' route under Rails since Fixnum/Float is re-opened
<kares>
but those methods are built-in so if we refactored to checking whether the cached method is built-in at call-site (instead of doing the isFixnumReopened() check) it would work
<kares>
or am I missing something here, does it not make sense?
<headius>
kares: no you're right
<headius>
the way it should work is by doing normal method caching but when it sees that the cache is the built-in + it follows the optimized path
<headius>
rather than a single boolean that kills all oto
<GitHub63>
jruby/master b679777 Charles Oliver Nutter: Temporary patch to frobnicate kwargs in indy mode....
<nowhereFast>
implementing Iterator worked, thanks headius, what is the reasoning for Enumerator not implementing it?
<GitHub61>
[jruby] enebo pushed 1 new commit to jruby-9.1.13.0: https://git.io/v7Pt3
<GitHub61>
jruby/jruby-9.1.13.0 d9473de Charles Oliver Nutter: Unused local.
<headius>
nowhereFast: Enumerator isn't a class, it's a mix-in
<headius>
so basically when you include it you're just copying a bunch of Enumerable methods into your class
<GitHub188>
[jruby] enebo pushed 1 new commit to jruby-9.1.13.0: https://git.io/v7Pt0
<GitHub188>
jruby/jruby-9.1.13.0 8384ec3 Charles Oliver Nutter: Temporary patch to frobnicate kwargs in indy mode....
<headius>
now I'm not sure what that from_iterable does
<headius>
if it just calls "iterator" dynamically, then you don't have to implement Iterable but you still need the method
<headius>
if it's a Java thing it would be looking for Iterable interface
<nowhereFast>
hmm.. what I've done is added an iterator method to Enumerator that does IterClass.new(self) and Iterclass implements Java::JavaUtil::Iterator, from_iterable seems happy with this, but not sure I've gone about it the best way..
<nowhereFast>
my use case is Enumerator.new do |yielder| #stuff yielder.yield.
<nowhereFast>
and giving this to from_iterable turns it into an observable that fires when subscribed to
<kares>
headius: thanks I will refactor (stumbled on smt similar anyways) and see if there are any failures
<headius>
kares: cool, go for it
<enebo>
subbu: you around and have a few minutes
<enebo>
subbu: we want to talk about optimizing keyword arguments
<subbu>
enebo, on a train from toronto --> ottawa .. wifi is mostly good, but occasionally it drops .. but around.
<enebo>
subbu: so perhaps I will write something up since plans changed a little this afternoon
<enebo>
subbu: largely the case is changing IR in a way where scenarios where last arg to a call is a literal hash of symbols we do not want to construct the hash neccesarily
<enebo>
subbu: if the call connects to a kwarg method we want to eliminate that extra construction...if it isn't then we will construct the hash on demand
<enebo>
subbu: IR's design though just makes it right away
<subbu>
ok .. i've forgotten the rray resolution logic on the receiving end.
<subbu>
does it rely on it inspecting type?
<enebo>
subbu: one could argue this is what inlining is for too
<enebo>
you mean parameters as an array to a method?
<subbu>
i meant: how does the receiver know there is a non-empty kw-arg hash?
<subbu>
*non-null
<enebo>
last argument to a call might be a kwarg or it might just be a hash as ordinary argument
<enebo>
receiver right now uses last argument and inspects what type it is
<enebo>
potentially even to_hash on last arg
<subbu>
right ... so type inspection.
<enebo>
correct
<enebo>
although if we have, for example, a call and we pass in a list of or kwarg values as just positional arguments
<enebo>
and then save the keys as operands to be remembered for binding
<enebo>
then on receiver side (via callsite or indy) we realize it is a kwarg receiving method we just pass those through (and somehow it resolves that -- but that is solvable -- let's assume that)
<subbu>
i think you will need a way of detecting presence of kw-hash on the receiving end .. so you might have to pass in a dummy arg to signal that args that follow are k-v pairs of an unconstructed keyword hash
<enebo>
if it is not a kwargs receiver we make the hash late
<enebo>
but at callsite we cannot know so we have to pass the data without making the hash
<enebo>
subbu: but the thing is we are not trying to make this optimization work for 100% of all kwarg methods since kwargs has lots of odd things in it
<subbu>
abstractly, you need to pass a signal to the receiver that there is a kw-hash (constructed or not is an orthogonal thing).
<subbu>
right now, becuase you construct a hash, type inspection is the signal.
<enebo>
subbu: so this is just about best way to model the last arg as a hash in IR without making an instance of a hash
<subbu>
if you want to optimize around that, you need a different signal.
<enebo>
subbu: at this point any call with hash literal as last arg we will send a signal
<enebo>
subbu: perhaps just a flag or boolean from the data on callbase
<subbu>
ok
<enebo>
subbu: or maybe a new create_kwarg instr
<enebo>
subbu: which just populates a thread local
<enebo>
subbu: I guess I will write these up in more detail and forward it
<subbu>
where is the create_kwarg instr added? receiver or caller?
<enebo>
caller
<enebo>
idea is it is represented implwise as a field on TC and only one ever exists at a time but it allows us to out of band kwargs craziness
<enebo>
and since we are not constructing it it is not huge cost
<subbu>
sure. thread-local makese sense.
<enebo>
but it feels implish to me to make this as an IR instr/concept
<enebo>
but I guess I don't know
<enebo>
so either making calls last hash arg sensitive or making new instr for the case where a hash arg may be this last arg are the two basic options
<subbu>
you can have create-kwarg added all the time .. for literal case, you optimize it implementatoin vis as a thread-local.
<enebo>
subbu: yeah I like the idea of that for ability to const prop it in case where it is literal as a variable but then used in a kwarg call
<subbu>
so, for that case, at runtime, hwen you prepare-call-args, you can handle that thread-local case differently by passing in a special java-arg in.
<enebo>
subbu: also it might be possible to use that in general hash cases too
<subbu>
so, the default implementation is always construct rubyhash.
<enebo>
subbu: if so in the latter case perhaps it is a new mechanism for hash and it is no longer an operand
<subbu>
optimized implementation is construct a special java type .. that is used by the type inspector on the receiving end.
<enebo>
yes
<enebo>
create_kwarg_hash has a rule where only one can exist at a time which is ok for call but it means IRBuilder needs to honor that
<enebo>
building this into all calls means there is no special rule
<enebo>
but it is all opaque to IR itself
<enebo>
if you think of this as a implementation/optimization of the implementation then baking it into calls makes more sense...If IR can reason with this in any way it then seems to make more sense as a new instr
<subbu>
i don't understand the only-one thread local constraint ... for one, i don't see why the kw-arg will be used anywere except in the call that immediately follows.
<enebo>
or making hash an instr perhaps
<enebo>
well only one because we do not want to construct the box for the hash data
<enebo>
if we can make 10 as thread locals then we did not make things faster but slower
<enebo>
subbu: if we had more than one then we basically might as well just make the RubyHash in the first place
<enebo>
subbu: I need to run now...afk
<subbu>
i am missing some details .. but, i'll go with this for now. i can read more in the note you prepare if you are doing this .. or when you write code for it.
<enebo>
ok
Joufflu has joined #jruby
nowhereFast has left #jruby [#jruby]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub112>
jruby/master f416bf9 Charles Oliver Nutter: Tag WeakRef specs that depend on triggering GC and tend to hang.
<lopex>
headius: are those really doable with mri ?
<headius>
well I think the issue is that it uses GC.start which we stub out
<headius>
so it's just dumb luck if we'll GC
<lopex>
yeah
<lopex>
same for phantoms I suppose ?
<headius>
if it used JRuby.gc it might be better but it's still pretty sketchy to test
<lopex>
does mri distinguish weaks and softs ?
<headius>
they do not as far as API Goes
<headius>
internally they might have a concept of soft but I have not seen it
<headius>
and there's no phantom either that I have seen
<headius>
I just got tired of them sporadically failing
<lopex>
headius: btw, I have that clusters on my tabs open, so I wont forget
<headius>
hmm I suppose I could have made our mspec config patch GC.start to JRuby.gc
<headius>
that might make it good enough
<headius>
lopex: ok
<headius>
I merged 2.4 to master with most case-folding stuff excluded for now
<headius>
there were only a few related tests
<lopex>
headius: that will be easier than folds
<lopex>
headius: oh ?
<headius>
this was for the regex \X?
<lopex>
yeah
<headius>
yeah just a few for casefolding
<headius>
String#casecmp tests
<headius>
I think maybe one or two capitalize tests
<lopex>
headius: so you did the enc aware folding ?
<headius>
I did not do anything specific to folding
<lopex>
ok
<headius>
if anything came in it was incidental in re-porting stuff
<lopex>
headius: btw, the official unicode docs are becoming pretty welcoming
<headius>
subbu: the debate we've been having is whether kwargs logic belongs within call as an inherent part of the call, or if it's better as a separate group of instructions that prep the call
<headius>
sorta like the debate we had about whether method lookup and caching should be an instruction or an inherent part of call
<headius>
it's clear we can't do it like we do now, where it's an opaque construction of a hash that might never be used
<headius>
lopex: oh yeah? Like what?
<headius>
subbu: combining it with all logic simplifies the change but means call has even more logic than it has now
<lopex>
headius: like the obviousness of what they do now
<headius>
having instrs like "CreateKwargs", "SetKwarg" etc might be easier but will increase IR and code size and obviously require more work to build
<headius>
I'm not sure how I feel about having call instrs that explicitly set up this weird "out of band" data but it's similar to framing and it would be easy to implement
<headius>
what happened with UTF-8 that it's no longer a 6-byte encoding?
<headius>
I have found docs that it was changed but not why
<lopex>
6 ?
<lopex>
headius: you're referring to normalization ?
<headius>
well even as recent as Java 8 spec, UTF-8 was described as 1-6 octets
<headius>
but it's not now, hence the change I had to make to the codepoint validation
<lopex>
well, afaik it's wrong
<headius>
so they decided they won't need chars largeer than 0x10FFFFFF or something?
<headius>
yeah to me it seems a bit short-sighted AGAIN