<GitHub131>
[jruby] eregon pushed 2 new commits to truffle-head: https://git.io/v1SBA
<GitHub131>
jruby/truffle-head c4c2c72 Benoit Daloze: [Truffle] Simplify encoding_converter_last_error by returning an Array.
<GitHub131>
jruby/truffle-head d88a101 Benoit Daloze: [Truffle] Simplify Regexp by caching the named_captures in Ruby....
<GitHub163>
[jruby] eregon closed pull request #4385: [Truffle] undefined is now the same as NotProvided.INSTANCE. (truffle-head...truffle-undefined-not-provided) https://git.io/v1DvV
<GitHub69>
[jruby] eregon pushed 14 new commits to truffle-head: https://git.io/v1SRs
<GitHub69>
jruby/truffle-head a1dbf12 Benoit Daloze: [Truffle] Rearrange undefined checks so they are done first.
pawnbox has quit [Remote host closed the connection]
<GitHub163>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v1S1v
<GitHub163>
jruby/truffle-head 8e56bac Benoit Daloze: [Truffle] Cleanup undefined from CoreLibrary, it's just NotProvided now.
pawnbox has joined #jruby
subbu|breakfast is now known as subbu
shellac has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
pawnbox has quit [Remote host closed the connection]
shellac has joined #jruby
pawnbox has joined #jruby
claudiuinberlin has quit []
<GitHub118>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v1Sbc
<GitHub118>
jruby/truffle-head 7007ea0 Benoit Daloze: [Truffle] Remove Rubinius::IdentityMap, Hash works just as nicely.
bbrowning is now known as bbrowning_away
<GitHub5>
[jruby] headius opened pull request #4388: Add call protocol to script body and separate non-protocol metas. (master...protocol-fixes) https://git.io/v1SNy
shellac has quit [Quit: Computer has gone to sleep.]
elia has quit [Quit: Computer has gone to sleep.]
<GitHub0>
[jruby] jmiettinen opened pull request #4389: Check permission to AccessibleObject#setAccessible(boolean) a better way (master...check_accessible) https://git.io/v1Sh8
subbu is now known as subbu|afk
bbrowning_away is now known as bbrowning
subbu|afk is now known as subbu
<eonwe>
Any ideas on what would be a better place to dump a useless class to do access checks in than in the same package as we're doing the checks in?
beawesomeinstead has quit [Read error: Connection reset by peer]
beawesomeinstead has joined #jruby
claudiuinberlin has joined #jruby
<headius>
co2 is slightly heavier than n3 so perhaps that's why
<headius>
oblate spheroid, heavier atomspheric compounds would trend to lowest point
alxs has quit [Ping timeout: 256 seconds]
<headius>
enebo: so that PR should go green now...there were some assumptions about scopes that prevented top-level script from getitng a right-sized version
<headius>
I have another branch here that cleans up specific-arity JIT stuff so it only emits one body instead of two
<headius>
so there will be either a full variable-arity method OR a full specific-arity method with a variable-arity wrapper
alxs has joined #jruby
<lopex>
headius: I thinks it's trade winds and the fact that northern places produce more co2
<enebo>
headius: assumptions in the PR or from 91.6?
<lopex>
release ?
<enebo>
lopex: getting closer
<chrisseaton>
> I have another branch here that cleans up specific-arity JIT stuff so it only emits one body instead of two
<chrisseaton>
headius: do you emit two method bodies sometimes and run different ones depending on the arity?
<headius>
enebo: assumptions generally in the root script logic
<enebo>
headius: and they have always been there?
<headius>
chrisseaton: if a method has only plain required args we have paths that map those straight through, but we still need a variable arg call path
<enebo>
headius: was this fallout from generated scopes
<headius>
before this branch we emitted both completely...now if there's a specific-arity path the variable-arity path just checks arity and calls it
<chrisseaton>
headius: we do that for lambda/proc semantic differences - didn't know you did it as well
<enebo>
chrisseaton: we have also discussed making a proc and lambda version since we cannot know ahead of time
<headius>
yes, wouldn't be difficult
<chrisseaton>
It's a source of bloat for us - tons of blocks in most code
<enebo>
chrisseaton: but we are not doing that currently
<headius>
only doing it for arity right now...we have for years
<headius>
this reduces the amount of code generated by something like 40-50%
<headius>
for specific-arity methods anyway
<headius>
code generation solves all ills
<headius>
eonwe: it should be sufficient to add a private field somewhere we never use and see if you can set it accessible, no?
<headius>
I didn't think setAccessible checked caller context for security
<eonwe>
headius: Yeah, private-field anywhere is okay. AccessibleObject#setAccessible does check for that 'suppressAccessChecks' IFF there's a security manager. That includes check to caller context
<GitHub29>
[jruby] headius opened pull request #4390: Specific arity jit cleanup (master...specific-arity-jit-cleanup) https://git.io/v1939
<GitHub105>
[jruby] headius closed pull request #4389: Check permission to AccessibleObject#setAccessible(boolean) a better way (master...check_accessible) https://git.io/v1Sh8
<GitHub96>
jruby/master 755fdb7 Charles Oliver Nutter: Merge pull request #4389 from jmiettinen/check_accessible...
<GitHub96>
jruby/master c54b9e4 Jarkko Miettinen: Check accesibility through a class that's in our control
<GitHub96>
jruby/master 592707d Jarkko Miettinen: Test if we can set accessible by trying to call AccessibleObject#setAccessible(boolean) instead of seeing if we have permission 'suppressAccessChecks'. We may not have that permission if we're not using a privileged classloader but can still setAccessible if (when) there's no security manager
<GitHub182>
jruby/master e3556a4 Thomas E. Enebo: Fixes #4349. -Xnative.enabled=false fails to load windows in kernel
<GitHub169>
[jruby] enebo closed issue #4349: -Xnative.enabled=false fails to load windows in kernel https://git.io/v1GQQ
<GitHub125>
[jruby] headius closed pull request #4388: Add call protocol to script body and separate non-protocol metas. (master...protocol-fixes) https://git.io/v1SNy
<GitHub51>
jruby/master e926a44 Charles Oliver Nutter: Move dynamic flags out of Constants to avoid sticky deps....
<lopex>
enebo: how many speced behaviors are there for kwargs ?
<enebo>
lopex: 14
<lopex>
lolz
<lopex>
enebo: why so obvious ?
<enebo>
lopex: yeah I guess there are quite a few
<lopex>
the cases ?
<enebo>
lopex: I am not sure if I would stand by 100% exhaustive but I have not looked at them recently
<lopex>
I think you might have wanted to say 12
<lopex>
er, was that a proper english ?
<enebo>
heh I have been trying to write a program which has nested closure compile at same time as parent method and I cannot get anything to fail
<lopex>
so many arbitrary rules ?
<enebo>
but then again I guess perhaps my code is so simple LVA cannot hit BB which goes away
<enebo>
lopex: for keyword arguments?
<lopex>
oh, well, I'm just taking your time waiting for the release
<lopex>
yeah
<enebo>
lopex: yeah I guess so…I only find two things really weird in kwargs
<lopex>
LVA ?
<enebo>
1. it is always the last argument .. so if you pass 200 args to a proc which receives 2 fixed vars it will still be the 200th element as the kwarg
<enebo>
2. If you do foo(a: 1, “b” => 2, c: 3) this will make an args hash and a kwargs hash where kwargs is [a, c] and normal args is [b]
<lopex>
go on, we should put that in the wiki
<enebo>
a third could be if kwargs is not a hash and it responds to to_hash but it returns nil then it just passes that object as an ordinary arg but I think this behavior exists for other things in Ruby similarly so it is not specifically a kwargs weirdness
<lopex>
enebo: any syntax quirks wrt a: and :a => syntaxes still ?
<enebo>
lopex: important part is key is a symbol not the syntax used
<lopex>
enebo: but the impl might say othewise :{
<enebo>
lopex: does it not work?
<nirvdrum>
enebo: Nevermind. I think I have my head around it.
<enebo>
lopex: I guess I could be wrong but I thought it worked
<lopex>
enebo: it works, but it's from 2.x transition right ?
<lopex>
the mixed mode
<enebo>
nirvdrum: it is weird they did not just do (rescue (splat (lvar)), (colon2)) or something like that in retrospect but the AST was originally their interpreter
<enebo>
nirvdrum: so in that sense it made sense but not so much anymore
<nirvdrum>
Yeah. I think I was getting thrown off by the sometimes presence of ArrayNode and SplatNode.
<enebo>
nirvdrum: ultimately they are making decisions on how we construct that array
<nirvdrum>
It appears that's just implied for the second child in ArgsPushNode or ArgsCatNode
<enebo>
nirvdrum: and for rescue the array is never actually returned so we could elect to not make an array at all
<enebo>
nirvdrum: but in other forms we would want it to be an array
<enebo>
nirvdrum: this AST design sort of makes that a little harder
bbrowning is now known as bbrowning_away
<lopex>
enebo, headius, nirvdrum: you think something akin https://github.com/nanosai/modrun might be useful for encoding modularization ?
<nirvdrum>
enebo: Actually, it still can be weird.
<nirvdrum>
It's fine. I'm just trying to figure out what assumptions I can actually make :-)
<enebo>
since we focus so much more on fixing working code we seem to miss more error cases
<nirvdrum>
I'm trying to handle this case from pry: rescue RescuableException, *jruby_exceptions => e
<nirvdrum>
Which is how I ended up down this rabbit hole.
<enebo>
ah
<nirvdrum>
That comes in as an ArgsCatNode with a LocalVarNode for jruby_exceptions.
<nirvdrum>
And I was expecting a SplatNode somewhere :-)
<enebo>
nirvdrum: and it could have been
<enebo>
nirvdrum: unless one will not to_ary/to_a?
<enebo>
nirvdrum: maybe it is that easy
<nirvdrum>
No idea. Of course, none of this is spec'd.
<nirvdrum>
Maybe it's languishing in an MRI test somewhere.
<enebo>
it might be in MRI maybe
<nirvdrum>
That's why I have my gist with various forms.
<lopex>
the raise from rescue ?
<enebo>
nirvdrum: hislarious we will process anything in building that rescue list
<enebo>
nirvdrum: I also remember reasoning that it has to be List, Splat, Cat, or Push
<enebo>
nirvdrum: but I must not have realized raw values would not be wrapped in a List
<enebo>
it is weird with as mutable/flexible as Ruby is that you cannot do ‘rescue a’
Puffball has quit [Remote host closed the connection]
<enebo>
oh you can
<enebo>
heh just not if it is an array
<enebo>
whoa the hole is deep here
Puffball has joined #jruby
<GitHub184>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v19wr
<GitHub184>
jruby/truffle-head 3e7997f Benoit Daloze: [Truffle] Use do...end for multiline blocks.
pawnbox has quit [Remote host closed the connection]
<GitHub155>
[jruby] hydrogen18 opened issue #4391: Metaspace fills with java.lang.invoke.LambdaForms$ over time https://git.io/v19rs
<GitHub184>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v19r7
<GitHub184>
jruby/truffle-head e750435 Benoit Daloze: [Truffle] Use do...end consistently for multiline blocks in core.
<nirvdrum>
enebo: I haven't even looked into whether type coercion occurs here.
<enebo>
nirvdrum: so our issue in IR is the runtime internal helper method will do an instanceof check to see if the exception type is an array and then walk all elements if so
<enebo>
nirvdrum: so no doubt that if is there for a valid case but also is broken in this case
<nirvdrum>
It's unlikely to be a real problem, I suspect.
<nirvdrum>
It's just misled me :-)
<enebo>
nirvdrum: yeah that’s true it is an unusual case which if someone did it they would end up writing to JRuby first and then realize MRI does not work
<lopex>
enebo: is it worth to profile that in the IR for that instanceof check ?
<lopex>
or instanceof is just so cheap in jvm ?
<enebo>
lopex: for which instanceof?
<enebo>
lopex: oh I know where it is
<enebo>
lopex: I just don’t know what case it was put there for
<lopex>
enebo: the one you mentioned in the helper for splat
<enebo>
lopex: I would be amazed if it was only for this case
<enebo>
lopex: looks like we probably store exceptions internally as Array as well
<enebo>
lopex: we build our exceptions as an RubyArray when it is really a list node
<lopex>
er, oh
<enebo>
lopex: so having an lvar which contains an array works
<lopex>
I think I get it
<enebo>
lopex: actually even args cat and push both make RubyArray as well
<enebo>
lopex: and those end up being indirected through a temporary variable
<lopex>
is it eaed ?
<enebo>
lopex: so only real difference is that the broken case comes via a lvar vs a tempvar
<enebo>
lopex: but then we have optimization passes so that lvar no doubt will also be a tempvar by the time we evaluate it
<lopex>
how does temp differ from a var in the IR ?
<enebo>
lopex: so we could build this non-array case with some IR which checks its type or maybe makes sure it is not an array
<lopex>
oh hmm
<enebo>
lopex: an lvar ends up as a different type of Variable operand which stores to Heap Scope
<enebo>
lopex: tempvariable can store whereever (interp and JIT do it their own way)
<lopex>
so potentially captured
<lopex>
er
<enebo>
lopex: if we realize nothing ever needs the lvar we will convert the lvar to a tempvar since those are cheaper and spill the value back to the lvar ar boundaries
<enebo>
lopex: which is largely any call boundary
<lopex>
just because those dont escape ?
<lopex>
er, I'm missing something
<lopex>
what's the samentics of lvar ?
<lopex>
enebo: btw, thank you for your patience :P
<enebo>
lopex: if you make a call it could potentially get its binding
<lopex>
this I understand
<lopex>
then you promote ?
<enebo>
lopex: we store back to dynscope if we make a call
<enebo>
lopex: but for places where we are not making calls we can decide not to and the temp store is just a local in java
<enebo>
lopex: arguably due to the amount of calls in Ruby this has been a questionable optimization but it can be very fast in the right places
<lopex>
wrrr, I'm having a feeling I understand all of this under different terms
<lopex>
doh
<lopex>
yeah
<lopex>
enebo: expecially computationally complex
<enebo>
lopex: going back to this bug I should probably just put an array test on this
<enebo>
lopex: in the case where it is not the expected array types push, cat, splat, or list I will raise if it is an array
<lopex>
enebo: I understand that
<enebo>
lopex: the exception type check will still happen as normal if it is some random object
<lopex>
the naming lost me
CustosLimen has quit [Ping timeout: 268 seconds]
CustosLimen has joined #jruby
<GitHub43>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/v19SJ
<GitHub175>
[jruby] nirvdrum pushed 2 new commits to truffle-head: https://git.io/v19SW
<GitHub175>
jruby/truffle-head fce94b5 Kevin Menard: Add a spec for rescue clauses that combine a splatted list of exceptions with a literal list of exceptions.
<GitHub175>
jruby/truffle-head f791368 Kevin Menard: [Truffle] Fixed rescue clauses that combine an exception list with a splatted list.
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
claudiuinberlin has quit []
tcrawley is now known as tcrawley-away
<GitHub154>
[jruby] eregon pushed 2 new commits to truffle-head: https://git.io/v19H6