shellac has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
pawnbox_ has quit [Remote host closed the connection]
e_dub has quit [Ping timeout: 268 seconds]
vtunka has joined #jruby
jensnockert has joined #jruby
mkristian_ has joined #jruby
jensnockert has quit [Ping timeout: 272 seconds]
<GitHub166>
[jruby] pitr-ch pushed 1 new commit to master: http://git.io/vZH2g
<GitHub166>
jruby/master f8d0c9f Petr Chalupa: [Truffle] make Hash#each_item immune to each overriding
skade has joined #jruby
shellac has joined #jruby
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pawnbox has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
vtunka has quit [Quit: Leaving]
skade has joined #jruby
samphippen has joined #jruby
samphippen has quit [Client Quit]
skade has quit [Quit: Computer has gone to sleep.]
CustosL1men has joined #jruby
blaxter has joined #jruby
samphippen has joined #jruby
drbobbeaty has joined #jruby
<GitHub167>
[jruby] pitr-ch pushed 2 new commits to master: http://git.io/vZHDo
<GitHub167>
jruby/master e530293 Petr Chalupa: [Truffle] Super uses given block even if arguments are passed explicitly
<GitHub167>
jruby/master de5c075 Petr Chalupa: Super uses given block even if arguments are passed explicitly
<GitHub15>
[jruby] pitr-ch commented on commit 7b78f76: Could we add a test for this? Maybe in general it could be helpful to have similar rules machine-checked. http://git.io/vZHSa
<GitHub152>
[jruby] pitr-ch pushed 3 new commits to master: http://git.io/vZH9D
<GitHub152>
jruby/master e5952d1 Petr Chalupa: [Truffle] allow Kernel#system and Process.spawn to be called with array of arguments...
<GitHub152>
jruby/master 592098f Petr Chalupa: [Truffle] code formatting
<GitHub152>
jruby/master 181d3c9 Petr Chalupa: [Truffle] replace Truffle primitive setting $? with allowed writes in core files
<GitHub62>
[jruby] pitr-ch closed pull request #3315: [Truffle] allow Kernel#system and Process.spawn to be called with arr… (master...master) http://git.io/vZZqT
<GitHub174>
[jruby] eregon commented on commit 7b78f76: Yeah, I'll discuss with Andreas, there are already perf warnings in truffle.... http://git.io/vZHQR
<GitHub196>
[jruby] eregon commented on commit 053458a: Looks great to me! I have a question about why we need to pass the number of arguments but that's unrelated. http://git.io/vZH7P
pawnbox has quit [Remote host closed the connection]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub58>
[jruby] eregon commented on commit de630e0: Nice! http://git.io/vZHdC
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
samphippen has joined #jruby
drbobbeaty has joined #jruby
samphippen has quit [Client Quit]
<GitHub67>
[jruby] chrisseaton commented on commit 053458a: The messages all look well documented. I think what we need to document now is what the different languages send for different syntax, and what things like the Java interop will send. On the Ruby side the protocol is currently very fragile. I'll start documenting how Ruby responds to messages and the messages it sends. http://git.io/vZQsU
pawnbox has quit [Remote host closed the connection]
<GitHub173>
[jruby] eregon commented on commit 089d126: This discards the message given and the messages hard-coded in CoreLibrary, is that not a problem? http://git.io/vZQCW
rsim1 has joined #jruby
pawnbox has joined #jruby
jensnockert has joined #jruby
mkristian has joined #jruby
rsim has quit [Ping timeout: 248 seconds]
yfeldblu_ has quit [Ping timeout: 246 seconds]
samphippen has joined #jruby
jensnockert has quit [Ping timeout: 260 seconds]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jensnockert has joined #jruby
pawnbox has quit [Remote host closed the connection]
cristianrasch has joined #jruby
bbrowning_away is now known as bbrowning
pawnbox has joined #jruby
mkristian has quit [Quit: This computer has gone to sleep]
<GitHub154>
[jruby] jtulach commented on commit 053458a: I tried to add some examples with languages I knew (e.g. Java, C, possibly JavaScript) into the Truffle documentation. Do you want to have your own document (pros: you control it, cons: nobody finds it) or would you consider to add the sample Ruby code into the Javadoc of Truffle?... http://git.io/vZQa1
jensnockert has quit [Ping timeout: 268 seconds]
skade has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
mkristian has joined #jruby
jensnock_ has joined #jruby
pawnbox has quit [Remote host closed the connection]
<GitHub72>
[jruby] nirvdrum commented on commit 089d126: I don't think it's a problem. We were already ignoring it in half the specializations (note: I probably wrote those, so that may not be a fair assessment). For whatever reason, Rubinius seems to build up its own error messages that sometimes aren't as detailed as the system-provided ones. While there is potential to maybe miss some context or a special-formed message that's easy to grep for, I think the trade-o
shellac has quit [Quit: Computer has gone to sleep.]
jensnock_ has quit [Ping timeout: 268 seconds]
<GitHub157>
[jruby] nirvdrum commented on commit ac6268d: Doesn't this change the semantics if `o` is `nil` or `false`? http://git.io/vZQ6X
mkristian has quit [Quit: This computer has gone to sleep]
shellac has joined #jruby
tcrawley-away is now known as tcrawley
pawnbox has joined #jruby
nirvdrum has joined #jruby
mkristian has joined #jruby
skade has joined #jruby
<GitHub75>
[jruby] eregon commented on commit ac6268d: well it's only for that example http://git.io/vZQD4
shellac has quit [Quit: Computer has gone to sleep.]
<GitHub152>
[jruby] eregon commented on commit 089d126: I think the filename for instance should be shown on ENOENT, which is not the case anymore:... http://git.io/vZQS3
<GitHub171>
[jruby] nirvdrum commented on commit ac6268d: Ahh, I guess I should have looked at more context. I guess that explains the `case 1`, too. I realize you're not the original author, but I think this spec is a bit confusing. Having a comment as to what's really being tested would be helpful. http://git.io/vZQS4
<GitHub5>
[jruby] nirvdrum commented on commit 089d126: Okay. I can roll some of these back. I'd still like to go with the general approach. The feedback loop of adding one sys error at a time is getting a bit cumbersome otherwise. http://git.io/vZQ9t
<GitHub133>
[jruby] eregon commented on commit ac6268d: The specdoc would ideally be enough :smiley: ... http://git.io/vZQHI
shellac has joined #jruby
CustosL1men has quit [Ping timeout: 265 seconds]
<GitHub186>
[jruby] kares pushed 11 new commits to master: http://git.io/vZQ5D
<GitHub186>
jruby/master bdaa82b kares: context cleanup - avoid backtrace.clone, remove private and less string concatenation
<GitHub186>
jruby/master be6a2bf kares: one ':' is enough on ": unhandled exception" & find-bugs-style cleanup
<GitHub186>
jruby/master 4e50bc7 kares: getName for JavaMethod
mkristian has quit [Quit: This computer has gone to sleep]
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
Aethenelle has joined #jruby
pietr0 has quit [Quit: pietr0]
vtunka has joined #jruby
CustosL1men has joined #jruby
<GitHub147>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/vZ7eq
<GitHub147>
jruby/master 893d10b Kevin Menard: [Truffle] Don't throw away the Rubinius contextual message in the `exception_errno_error` primitive.
<GitHub167>
[jruby] nirvdrum commented on commit 089d126: I think 893d10b4b65ab09c29551faf9e6c6f8e4c483945 strikes up the balance we're looking for. If you find another case that's not quite right, please let me know. That commit more closely matches what Rubinius does. http://git.io/vZ7eh
<GitHub77>
[jruby] chrisseaton pushed 1 new commit to truffle-objspace: http://git.io/vZ7Ui
<GitHub77>
jruby/truffle-objspace 8d06e9c Chris Seaton: [Truffle] Transform recursion to looping for arbitrarily deep ASTs.
<GitHub177>
[jruby] chrisseaton commented on commit 053458a: I'll certainly start to write them - we can tweak where they live at any point. They probably belong in Truffle documentation because people are going to want to know how key languages will respond to them, and if we have a range of languages they can also use that to determine what they should do for their own languages. http://git.io/vZ7TI
<GitHub36>
[jruby] chrisseaton pushed 2 new commits to master: http://git.io/vZ7mn
<GitHub36>
jruby/master 5fae7eb bitfurry: [#3324] modified _id2ref to raise RangeError...
<GitHub36>
jruby/master 772f173 Chris Seaton: Merge pull request #3327 from bitfurry/master...
<GitHub101>
[jruby] chrisseaton closed issue #3324: _id2ref should raise RangeError rather than return nil for no object found http://git.io/vZMIF
skade has quit [Quit: Computer has gone to sleep.]
mkristian has joined #jruby
<GitHub109>
[jruby] eregon commented on commit 893d10b: Nice!... http://git.io/vZ7Y2
skade has joined #jruby
samphippen has joined #jruby
<GitHub49>
[jruby] eregon pushed 1 new commit to master: http://git.io/vZ73K
<GitHub49>
jruby/master 2a60605 Benoit Daloze: Remove error log from #3327.
elia has quit [Read error: Connection reset by peer]
elia has joined #jruby
colinsurprenant has joined #jruby
nirvdrum has quit [Ping timeout: 240 seconds]
nateberkopec has quit [Quit: Leaving...]
vtunka has joined #jruby
shellac has quit [Read error: Connection reset by peer]
shellac has joined #jruby
<GitHub129>
[jruby] eregon commented on commit 7b78f76: The `-J-G:+TraceTrufflePerformanceWarnings` flag would show:... http://git.io/vZ7CQ
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
TheWhip has joined #jruby
subbu has joined #jruby
<TheWhip>
Hi everyone, I am just starting off in jruby. Have been working with ruby for past 6 month. wha could be a good starting point?
enebo has joined #jruby
samphippen has joined #jruby
mkristian has quit [Quit: This computer has gone to sleep]
TheWhip has quit []
CustosL1men has quit [Ping timeout: 264 seconds]
<TheWhip>
hi
TheWhip_ has joined #jruby
nirvdrum has joined #jruby
<TheWhip_>
hi
<TheWhip_>
I have worked in ruby for the past 6 months. Thinking about starting Jruby. What would be a good place to start?
elia has quit [Read error: Connection reset by peer]
elia_ has joined #jruby
<rtyler>
TheWhip_: I'm not sure what to tell you, it really depends on what you're trying to learn and build
TheWhip_ has quit [Client Quit]
<GitHub29>
[jruby] nirvdrum commented on commit 893d10b: I thought of that and for some reason didn't come up with the simple solution of using a guard. I'll fix up shortly. http://git.io/vZ705
Aethenelle has quit [Read error: Connection reset by peer]
nateberkopec has joined #jruby
tenderlove has joined #jruby
havenwood has joined #jruby
nateberkope has joined #jruby
nateberkopec has quit [Read error: Connection reset by peer]
nateberkope has quit [Read error: Connection reset by peer]
<GitHub113>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/vZ7iT
<GitHub113>
jruby/master 6b911f3 Chris Seaton: [Truffle] Formatting.
CustosL1men has joined #jruby
nateberkopec has quit [Read error: Connection reset by peer]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nateberkopec has joined #jruby
samphippen has joined #jruby
<GitHub21>
[jruby] chrisseaton pushed 1 new commit to truffle-objspace: http://git.io/vZ7DW
<GitHub21>
jruby/truffle-objspace 4dcc1ed Chris Seaton: Merge branch 'master' into truffle-objspace...
donV has quit [Quit: donV]
<GitHub134>
[jruby] chrisseaton pushed 1 new commit to truffle-objspace: http://git.io/vZ7SB
<GitHub134>
jruby/truffle-objspace 5596ea0 Chris Seaton: [Truffle] Removed unused pauseAllThreadsAndExecuteOnOneThread
lance|afk is now known as lanceball
mkristian has joined #jruby
vtunka has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
donV has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pawnbox_ has joined #jruby
samphippen has joined #jruby
mkristian_ has joined #jruby
vtunka has joined #jruby
pawnbox has quit [Ping timeout: 244 seconds]
mkristian has quit [Ping timeout: 246 seconds]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
vtunka has quit [Read error: Connection reset by peer]
<headius>
morning
<GitHub178>
[jruby] kares created test-remove-get-indexed-reader-alias (+1 new commit): http://git.io/vZ5fx
<GitHub178>
jruby/test-remove-get-indexed-reader-alias 20fdb55 kares: remove support for aliasing Java indexed getters as Ruby readers (fixes #3262)...
<GitHub40>
[jruby] kares opened pull request #3328: remove support for aliasing Java indexed getters as Ruby readers (master...test-remove-get-indexed-reader-alias) http://git.io/vZ5Ju
<headius>
no, but I do have a pretty clear picture how I'll optimize it
pawnbox_ has quit [Remote host closed the connection]
<headius>
it should be fairly simple with indy
<chrisseaton>
headius: is it you that maintains psych? it looks in the repo like the Java component of it is tiny - is that the case or is there some other complexity I can't see
<chrisseaton>
we need yaml for Truffle pretty soon
<headius>
the java component is about the same size as the non-libyaml C bits
<headius>
java component uses snakeyaml as its library
<chrisseaton>
yeah and it's just a few hundred lines, right?
<headius>
something like that, yeah
<chrisseaton>
ah great - that should be easy then
<headius>
I'm not sure how big snakeyaml is, but I'd guess it's similar to libyaml
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton>
I looked at a pure Ruby yaml implement by Ola, but it didn't even work with MRI 1.9 even after a bit of trying
cremes has quit [Ping timeout: 252 seconds]
<headius>
yeah, that was a port of the old syck yaml engine
<headius>
I believe
<headius>
then he redid it in Java as yecht
<chrisseaton>
lots of sytanx and encoding issues on 1.9 and above
<headius>
there's no pure-Ruby compatible yaml that I know of
<headius>
snakeyaml is about 15kloc
<headius>
Tim's approach is kinda like what I will do, but mine will have zero allocation
vtunka has quit [Read error: Connection reset by peer]
<headius>
kwargs and simple args should be equivalent speed and generally just register mapping
<rtyler>
it's busy in here so headius must be feeling better
<headius>
I'm getting there
<headius>
sudafed is a hell of a drug
cremes has joined #jruby
<headius>
enebo: seems like call-side kwargs are a lot easier to map than receive-side
<headius>
basically only symbols become kwargs, any other keys are treated as an implicit hash arg
<chrisseaton>
useful for comparing if it is the same performance
<headius>
chrisseaton: ahh yes, that will be interesting
<headius>
should be when I'm done
<headius>
but I want to do it right in IR rather than one-off in JIT
<headius>
indy is a hell of a drug
<enebo>
headius: yeah since we know the kwarg is a literal
pawnbox has joined #jruby
<headius>
enebo: right...the case of passing it from an opaque operand is out of scope for what I'm doing, and IR should learn to optimize that later anyway
<enebo>
even more interesting once inlining is working too
<headius>
so really all I need to have as part of call site descriptor is what the names + operands are to build the literal kwargs portion
<headius>
given that I can map whatever it is straight through
<headius>
MAAAAGIC
<enebo>
yeah ultimately that “hash” can just fall out as unused once it inlines as dead code but as you said last week that will not help calling into native-lwarg using APIs
<chrisseaton>
and you have to do this once per cached method at the call site, right? as the resulting methods could have different kwargs in different orders?
<headius>
chrisseaton: order doesn't matter much, but yes, method handles would adapt the call side kwargs to receive side by shifting them into place
bb010g has quit [Quit: Connection closed for inactivity]
<headius>
enebo: yeah, native side will require some enhancements to JRubyMethod binding
<headius>
but it's doable
<enebo>
but native would be main reason for doing this if we assume hot code will inline
shellac has quit [Read error: Connection reset by peer]
shellac_ has joined #jruby
<enebo>
or I suppose perhaps faster value binding on a polymorphic site
<enebo>
which no doubt happens
samphippen has joined #jruby
<headius>
yeah, unless we're inlining poly calls it will be much cheaper for me to just have N call site adaptations for them and let hotspot decide what to inline
samphippen has quit [Client Quit]
<headius>
chrisseaton: order actually doesn't matter *at all* as long as the incoming values are evaluated left to right
<headius>
both caller and callee could just treat them as natural ordered keys after any required kwarg check is done
<headius>
I suppose it could matter if they're not going to kwargs but into a hash, where insertion order might matter to some madman, but even then it's just a matter of preserving insertion order when lazily constructing that hash
<headius>
I'll know whether I need to bother with that when I bind the site
<chrisseaton>
I asked about order because we do it by agreeing a ordering contract between the caller and callee, so they can be read out like normal positional arguments
<headius>
sure, that's simple enough
<headius>
still need to handle required kwarg errors in proper order and preserve insertion order in the hash (and probably kwrest) cases
<headius>
enebo, subbu: yeah this is going to need to be logic in the call since treating it as a plain operand means it's too far removed
<headius>
so calls will have both args and kwargs Operand[]
<subbu>
headius, enebo ok .. i cannot discuss this right now since I am in the middle of something else .. but, that seems like it might need a different representation when we were talking about it last week.
<subbu>
not sure about the specific changes yet, but you guys can work it out and i can comment on it, if i have any, i.e.
<headius>
yeah, it would be nice if it could be a simple operand but the layout can't really be divorced from the call
nateberkopec has quit [Quit: Leaving...]
yfeldblum has joined #jruby
bbrowning is now known as bbrowning_away
nirvdrum has joined #jruby
vtunka has quit [Read error: Connection reset by peer]
<chrisseaton>
The -Pj2ee failure seems intermittent
<headius>
lovely
elia_ has quit [Quit: Computer has gone to sleep.]
<headius>
enebo: bleh, AST encodes hash args as a HashNode, so I need to do some special logic in builder
<headius>
right now it just walks it blindly like any other node in args list
nateberkopec has joined #jruby
<enebo>
hash args as hash node...madness
<headius>
unless you think AST should change
baroquebobcat has joined #jruby
<headius>
flatten kwargs layout into CallNode
<enebo>
headius: hmm we can definitely mark the hash as a different node type and extend hashnode
<enebo>
yay I did something and intellij sees hava version null
<enebo>
It was just working :|
<chrisseaton>
I wonder if it's worth optimising for the general case of a hash being created with literal keys, and then immediately read from the other side of a call - optimise old-style manual keyword arguments as well
<enebo>
chrisseaton: can you optimize syntactic hash arg?
<headius>
chrisseaton: you mean as separate lines?
<enebo>
chrisseaton: for us it is required to be a rubyhash at method binding
<chrisseaton>
for us it only works if there is no explicit hash - but if it did that would be better
<enebo>
chrisseaton: but we can differentiate the symbol hash args from non-symbol
<enebo>
I am somewhat surprised we don't
<headius>
yeah, I could see optimizing the case where it's a separately constructed hash but I'd bet there's not many cases of it
<headius>
the literal syntax has been present for a long time
<headius>
or rather, I'd bet there's not many cases that don't also actually USE that hash as a hash
<headius>
in which case you'd have to construct it anyway
<chrisseaton>
well you'd have to support operations *as if* it were constructed
<headius>
right
<chrisseaton>
if someone wants a real hash just so they can call .size, you don't need to reify for that
<headius>
I know you can eliminate it for some number of cases
<enebo>
Sorry using emacs to examine this but in parser we make an ArgsTailHolder for keyword args
<enebo>
and then I believe we examine that when we make call nodes
<headius>
not as far as I see
<enebo>
so we can just construct a new instance
<headius>
in bin/ast it's just a HashNode
<headius>
in the args list
<enebo>
it is
<enebo>
but it is not before it is made a hashnode
<headius>
oh I see
<headius>
it's a transient struct you use
<enebo>
e.g. we make a hashnode when we construct the callnode out of a holder object
<headius>
so we could encode it deeper into the call
<headius>
I can do this without that but it will be more complex build
<enebo>
yeah the parser is depth first and this bubles out
<headius>
and I'll basically be putting back info we lost
<enebo>
wow I take IDEs for granted in Java now :)
vtunka has joined #jruby
<headius>
cute, HashNode encodes kwrest as null key with some value
<headius>
enebo: I'm just going to go with builder changes for now
<enebo>
headius: you know I suspect you can do this without changing the AST in builder
<headius>
oh, I'm sure we can
<headius>
I was just musing on whether the AST should have a richer representation of kwargs in a call
<enebo>
headius: there is a buildArgs or something and you can just call a different method for getKeywords on argsnode
<headius>
yeah
<headius>
that's the plan
<enebo>
headius: my only thought on this is how something like foo “a” => 1, a: 2, “b” => 3, c: 4 is handled?
<enebo>
I am guessing first “a’ and “b” are not keyword args
<headius>
right now it's all one hash, but it could either bail to slow version or encode as separate hash arg + kwargs
<enebo>
second a and c are stuffed into argstailholer
<headius>
only the symbol keys can end up in receiver kwargs
<enebo>
headius: this is one place we could simplify this
<enebo>
in the AST
<headius>
that call would also require non-zero required args to hold the rest of the hash
<enebo>
I guess the issue is if the method to the call does not use kwargs it should convert back to an old style syntax hash
<headius>
so there's a lot of weird complexity
<headius>
er, non-zero positional args
vtunka has quit [Client Quit]
<enebo>
I think the fact that foo a: 1 can be either a kwarg or a single hash arg is confusing at AST
<headius>
if the site encodes that there's "a" and "b" in a literal hasn plus :a and :b in a kwargs has, the call site adaptation can decide what to do based on target
<enebo>
but I guess it is still not know at IRBuilder either
<headius>
hasn,has=hash
<enebo>
yeah it has to look at target in 100% of all cases
<headius>
for sure
<headius>
or at least it has to look at target or bail to full hash
<enebo>
yeah I think using IRBuilder is a better place now
<headius>
bail out isn't a bad option for this case because it's super funky
<enebo>
yeah
<headius>
"Don't do that."
<enebo>
I would say if you encounter mixed you should not even try for sure
<headius>
I'm sure not going to do anything with it right now :-)
<enebo>
honestly I find it confusing they even allowed it
<headius>
well, because you had it before
<enebo>
I guess it was for backward compat
<enebo>
since people probably mix symbol and string keys
<enebo>
yeah
skade has quit [Quit: Computer has gone to sleep.]
<headius>
like you might have symbols for known IDs plus strings for e.g. stuff from environment
<headius>
spawn/popen has some weird cases like that
<headius>
env vars aren't mapped as symbols
<headius>
etc
<enebo>
but I am talking about homogenous access
<enebo>
but I still see why they did it :)
<enebo>
hmmm if only symbol did not exist
skade has joined #jruby
<enebo>
immutable base string with mutable extended string type!
bbrowning_away is now known as bbrowning
<enebo>
yay
skade has quit [Client Quit]
CustosL1men has quit [Ping timeout: 240 seconds]
shellac_ has quit [Quit: Computer has gone to sleep.]
<headius>
oh thank goodness
<headius>
I just tried to do foo[a, b:2] = 3
<headius>
MRI always encodes it as three arguments
<headius>
I was worried it would have to be receiver-side like def []=(a, c, b:)
<enebo>
headius: so no way to have actual kwarg in that case?
<enebo>
not that I care
<headius>
that definition is accepted but the call still tries to pass three args
<headius>
not two args plus kwargs
<headius>
of course, if we told them about this they might fix it :-)
<enebo>
yeah feels weird to have syntactical shortcut method name get kwargs
<headius>
foo[a, *c, b:3, **d] = e
tcrawley is now known as tcrawley-away
<headius>
valid call
<enebo>
nice
<headius>
b:3 and d get mooshed into one hash argument though
<headius>
no kwargs processing
<enebo>
but why would it accept **d?
<headius>
it's treated just like {b: 3, **d}
<enebo>
ah poor man’s merge
<headius>
yeah
<enebo>
semantically confusing for a call
<enebo>
it makes sense in a literal
<headius>
they should add hash arg destructuring like array destructuring :-D
<headius>
def foo(a: (b:, c: (d:)))
rcvalle has joined #jruby
<headius>
I have no idea what that would mean
<enebo>
mix it too
<headius>
hah
<enebo>
def foo(a: [b, v]
<headius>
def foo(a: (b, c = 1, *d))
<headius>
turing-complete argument descriptors
<enebo>
or extend it as a destructuring language and use ‘&’
<enebo>
def foo(a: (b => &name))
<headius>
hah
<headius>
ok, my head hurts and I don't think it's the cold
<enebo>
we could make a completely unintellgible destructuring language
<enebo>
but you could do all that unpesky unpacking in one line
<GitHub134>
[jruby] eliaslevy opened pull request #3329: Fix java_implements for multiple interfaces (jruby-1_7...fix_interface_string_join) http://git.io/vZ5bi
<enebo>
“unpesky”
<headius>
ugh, I think I do need to have something from parser
<headius>
I can't distinguish this HashNode from any other hash
<headius>
so I can't process it like it's kwargs
samphippen has joined #jruby
<headius>
I don't think I can assume that a hash directly in args list means it should be treated like kwargs
<enebo>
headius: no but it is a special node in argsnode no?
<headius>
no, it's just a HashNode
<headius>
in the Node[] of args
<enebo>
int keywordIndex = argsNode.getKeywordsIndex();
<enebo>
int keywordsCount = argsNode.getKeywordCount();
<enebo>
oh this is on wrong side
<enebo>
heh
<headius>
oh, I do have keywordsIndex in ArgsNode
<headius>
if that's nonzero I can always treat as kwargs?
<enebo>
well keywordsIndex is where they start
<enebo>
and count is how many
<enebo>
but if there is non-symbol key then it is not a kwarg
<headius>
there's just one hash node
<headius>
regardless of how many kwargs
<enebo>
at least I would bet on that being possible
<enebo>
headius: so we are talking about definition or call
<headius>
call
<enebo>
ah then no
<headius>
I'm working from call forward
<enebo>
I think everything I have said today is about other side
<enebo>
:|
<headius>
heh
<headius>
I was talking about CallInstr though
CustosL1men has joined #jruby
<headius>
receiver side definitely has all info encoded already because it has to
<enebo>
in parser we find “assocs” and stuff them all in a HashNode
blaxter has quit [Quit: foo]
<headius>
right, ok
<headius>
and if it's kwargs then ArgsNode.keywordIndex = n
<enebo>
if we want to have symbol vs non-symbol stored we can make a holder and keep track of both but that will complicate signature I think
<headius>
where n is always last arg in Node[] args
<enebo>
but callnode has none of that does t?
<headius>
no, none of it
<enebo>
oh yeah kwargs can only be last argument
<headius>
that's what I was talking about doing
<headius>
adding the actual arg list layout to CallNode rather than opaque ArgsNode
<enebo>
but it might be mixed with non-symbol keys
<enebo>
you keep saying ArgsNode but you mean args list right?
<headius>
I mean whatever this is in CallNode: private Node argsNode;
<enebo>
argsNode in CallNode is a ListNode always
<headius>
ahh ok
<enebo>
and last one may or may not be a kwargs or syntax hash or both or none
<headius>
so it's Array when it's not ArgsCat or ArgsPush
<headius>
those are why I was trying the foo[] case
<headius>
praying they didn't also do kwargs
<enebo>
if it is a args[length] == hashnode then it might be a kwarg
<headius>
that's not good enough :-)
<enebo>
at parser level we know it is an assoc arg
<headius>
no might
<enebo>
we cannot know it is a kwarg in parser
<enebo>
we can guess
<headius>
but we know it's a literal hashy arg syntax
<headius>
that's enough for me if I can guarantee that
<enebo>
well then examine last arg to see if it is a hashnode and then see if it contains symbol node keys or not
elevy has joined #jruby
<enebo>
it may be mixed but if we make that two things then we will need to update arity and signature
<headius>
I don't know if MRI parses foo(a, {b: c}) differently than foo(a, b: c)
<headius>
I tried opt and rest and they DON'T slurp
<enebo>
yeah req must get an arg
<headius>
so kwargs has higher precedence than opt and rest
<enebo>
so this had to be slurp or error
<headius>
but lower than req
<enebo>
yeah
<headius>
seems arbitrary but I don't think it matters much
<enebo>
that is true and lower than pre or post req
<headius>
yeah
donValentin has joined #jruby
<headius>
so process pre, process post, process kwargs, process kwrest, process opt, process rest
<headius>
basically
<enebo>
so I think any last literal hash arg may be kwarg if kwarg is in play and there are enough reqs
donV has quit [Ping timeout: 246 seconds]
<enebo>
but opt’d kwargs must make it back into a hash if not enough reqs
<headius>
def foo(a, *b, c:); p a, b, c; end; x = {"b" => 2, c: 3}; foo(1, x)
<enebo>
and also cope with mixed usage
<headius>
prints 1, {"b" => 2}, 3 for a, b, c
<enebo>
yeah
<enebo>
this is mixed case
<headius>
so after kwargs are peeled out -- which only includes symbol keys, remainder goes into rest
<enebo>
or to a missing req
<headius>
def foo(a, *b, c:, **d); p a, b, c, d; end; x = {"b" => 2, c: 3, d: 4}; foo(1, x)
<enebo>
if this one had one but req is higher prec
<headius>
and that does what you expect, d gets a hash with the extraneous key
<enebo>
yeah
<headius>
the rest is the same
<headius>
ok
<headius>
so I guess it doesn't matter if I always treat the incoming hash in a call as potentially kwargs
<enebo>
so I think if last arg is hash you look for homogenous set and probably bail if not to make this simpler
<headius>
if there's symbol keys they will get slurped up by keyword args in all cases anyway
<headius>
if the keys aren't there, rest/kwrest logic wins
<enebo>
but any last arg hashnode is ok because they implcitly destructure the thing :)
<headius>
yeah
<headius>
ok
<headius>
that simplifies it, oddly enough
<enebo>
problems like this is why I drive all the way to work every day
<headius>
I'm probably still going to punt on the mixed case for now though and only have a smart call when it's plain literal symbol kwargs
<enebo>
yeah please don’t try mixed case :)
<headius>
heheh
<headius>
chrisseaton: got all that?
<chrisseaton>
hm? no?
<headius>
heheh
<headius>
just teasing apart the many oddities in kwargs and argument handling
havenwood has joined #jruby
<headius>
oddities nobody will ever use except pry
<chrisseaton>
this is why it's simpler the only optimisation you provide is a hash created before a call, and consumed in a call and doesn't escape the callee, that should be simpler
<enebo>
headius: can you comment this somewhere about implicit destructuring and how you can assume hashnode at end might be kwargs…not sure where but you obviously will be writing code around that
<headius>
yeah ok
<headius>
I'll write it up somewhere appropriate
<chrisseaton>
e.g. should you be able to find optimised kw hashes via ObjectSpace
<headius>
chrisseaton: I disagree with that
<headius>
there's nothing about straight-through kwargs that implies a hash needs to be there
<enebo>
headius: yeah I don’t think I knew about kwargs destructuring like that which means I am not sure I have ever seen a syntax spec/test for it
<headius>
the hash only needs to be there if you ask for it by not having receiver-side kwarsg
<headius>
just like an implicit block doesn't show up as a Proc in ObjectSpace unless it's explicitly reified
<enebo>
yeah I also disagree…it being seeable as a hash is an impl side-effect isn’t it?
<headius>
keyword args are implicit in the same way if they map directly
<enebo>
it is language syntax on both sides in a simple kwargs case
<headius>
if you should see all optimized kwargs hashes in ObjectSpace then you should also see all optimized argument lists as Arrays
<headius>
which would be nonsense
<headius>
and not useful since those arrays only exist for purposes of call protocol and are never directly addressable by user code
<codefinger>
i almost feel like that PR does more harm than good now. no one is going to put the effort into to get it in shape unless they are sure it will be accepted by ged
<headius>
yeah, still building in proper evaluation order right now
<enebo>
headius: ah you just made me realize an interesting aspect to this
<headius>
I haven't decided if I want to do any magic to order these in CallInstr or just do that as part of binding later on
<headius>
I don't expect interpreter is going to be easy to optimize kwargs through given CallSite and limited signatures
<enebo>
headius: we have a chance after running compiler passes to propagate that temp in place
<enebo>
headius: which means we can detect a kwargs scenario more than we could in AST
<headius>
best it can probably do would be an array of IRubyObject meant to be key, value, key, value and CallSite can either try to piece it together or just make the hash
<enebo>
headius: but I don’t know how do to it :)
<headius>
ahh, yes I suppose so
<headius>
for literal kwargs that we're interested in, though, they'll almost always be literal symbol directly in the pair
<headius>
the other form falls into non-literal kwargs destructuring
<enebo>
headius: yeah I would not even try to tackle that right now either
<enebo>
headius: just realized it might be possible
<headius>
note the string gets built separately here but the symbol doesn't because it's atomic
<headius>
so we get that much for free
<headius>
the symbol is directly in the pair
<enebo>
headius: if we ever decompose Ruby hash to something simpler in Ruby this might become important
<headius>
this construct might make sense for Hash too but I'm not doing that right now
<headius>
it already aggregates a list of KeyValuePair
<headius>
this is basically just an operand for KeyValuePair
<headius>
(a non-retrievable operand)
<enebo>
I see
<enebo>
It possibly should be an operand as well
<headius>
it's more convenient than introducing a separate field into CallBase for a list of KeyValuePair
<enebo>
when we run passes we need to examine all operands in the instr
<enebo>
well some of them
<enebo>
like looking for variables or simplifying operands
tcrawley-away is now known as tcrawley
<enebo>
so this special encapsulation needs to be able to expose the operands it encloses
<enebo>
for things like simplifyOperand
<enebo>
well some of them == some passes
yfeldblum has joined #jruby
<enebo>
which means this extra special operand you have should probably be a composite operand
<headius>
eek...interpreter uses an intermediate ArrayList for splatted args
<headius>
talk about heavy
<enebo>
yeah
<headius>
that could be done as just two IRubyObject[] allocs
<headius>
at worst
<enebo>
true
<enebo>
I am somewhat surprised it ia still an arraylist
<enebo>
I would say it might be different in interpreterengines (which replicates some call code but splats would not be part of those)
<headius>
it's in the isntr
<headius>
instr
<headius>
prepareArgumentsComplex
<enebo>
headius: yeah perhaps it will show up in a bench too
<enebo>
headius: assuming we have any bench which uses rest arg
<enebo>
// ENEBO: we can probably do this more efficiently than using ArrayList
<enebo>
I just did not bother to go back whenever I wrote that comment and fix it
<enebo>
headius: this though is potentially more tan two primitive arrays if foo(*a, *b, *c)
<enebo>
but only two per splat
<headius>
that's true
<headius>
so n + 1 array allocs where n = number of splats
<enebo>
it also is egregious to have used n eltOks :)
<enebo>
no doubt we can just array copy from the ruby array itself
<enebo>
watch startup time bump by 10% because rubygems uses a splat for every call :)
<enebo>
oh I remember why I did not fix this
<enebo>
headius: below my comment subbu (ignore this subbu) points out we can greatly simplify zsuper/non-zsuper processing of splats
<headius>
our protocol always has hash args as last item before closure, right?
* subbu
ignores
<headius>
I'm going to wire this up the dumb way, creating hash in CallBase
<enebo>
headius: so I think it was laziness because I did not want make two versions of prepareArgumentsComplex
<headius>
so I can at least confirm it's working
<enebo>
yeah we look at last arg
<headius>
heh, I don't think we handle mixed hash args right yet anyway
<enebo>
we do not
colinsurprenant has quit [Quit: colinsurprenant]
<enebo>
headius: It would not be so hard to make it work but closures are pretty mucked up so I did not want to tag that one until revisiting closure call protocol and nailing that algo for binding values
<headius>
well this is working with my changes in place: def foo(x, a:); p x, a; end; foo(1, a: 2)
<headius>
CallBase arg setup builds the hash now
<headius>
that's kinda all I need to make JIT do the smart thing :-\
<enebo>
ah after a day I figured out why intellij worked and stopped working
<headius>
heh, literal hash isn't doing "small hash" right now either
<headius>
that would be savings in interpreter too
colinsurprenant has joined #jruby
<enebo>
I opened it from CLI earlier but do not have Apple Java installed so it did not start via spotlight
<enebo>
geez if I only did things one way I would never get confused
<enebo>
heh
<enebo>
headius: somehow I think I am regretting introducing keyvaluepair
<enebo>
headius: it was a primitive array of length * 2
<headius>
two-field object is smaller than array in memory
<headius>
I have no idea what other impact it might have though
<headius>
array needs additional header bits for length
<headius>
so, 32ish bits
<enebo>
but the keypairs still need a container?
<enebo>
and this is not even a primitive array
<headius>
hmmm
<headius>
I guess my HashPair operand doesn't need it
<headius>
I'm really only getting toString from it right now
<enebo>
yeah so for cleannes I used List<> but that is wastely in memory and in access since it also creates an iterator
<headius>
if I just make HashPair have two fields you could use that in Hash operand
<enebo>
I am not sure how much it actually matters though
<headius>
but you do still use KeyValuePair in AST
<enebo>
I made it in AST and IR just makes a different one
<headius>
heh, how about just have these all implement Map.Entry :-P
<enebo>
so in both cases a primitive array exists
<headius>
then it can just be directly in the operand or some AST node if you want the abstraction
<headius>
HashNode currently aggregates KeyValuePair<Node, Node>
camlow32_ has joined #jruby
<subbu>
headius, enebo quick comment. whatever fix you guys come up with .. make sure that getOperands() sees the new operands .. otherwise, all dataflow analyses will be blind to the keyword arg.
<headius>
HashPair and Hash operands in IR don't need to use KeyValuePair at all if HashPair implements Map.Entry
<enebo>
It think KVP<>[] pair would be better
<headius>
subbu: it's in there
<subbu>
k
<enebo>
subbu: yeah I mentioned that one too
<headius>
I added a HashPair operand for kwargs and CallBase already crushes all forms of input into a single Operand[]
<headius>
should be doing the right thing
<headius>
HashPair looks nearly like Hash except there's only one pair
<enebo>
headius: so for analysis we need to access Hash which access HashPair which accesses Key and Value operands
<headius>
if I modify Hash to aggregateHashPair most of that logic will be shared
<enebo>
headius: so this is 2 deep retrieval
<headius>
right now Hash is a List<KeyValuePair> anyway
<enebo>
yeah
<headius>
it would be a HashPair[] if I made the change
<headius>
and HashPair would not use KeyValuePair
camlow325 has quit [Ping timeout: 255 seconds]
<enebo>
perhaps make KeyValuePair just be HashPair
<headius>
for this, yeah
<enebo>
oh but we use it in AST
<headius>
but I need it to be an operand
<headius>
right
<enebo>
ok perhaps we fix that later
<headius>
either we use KVP in both places or we have two structs that are basically the same thing
<headius>
except one is an IR operand and one is for AST
<enebo>
you make a new operand and I will change AST to not use KVP and we can then just have a single pair object which is an operand
<headius>
ok
<enebo>
but having two for now is no big deal
<headius>
should I make Hash use HashPair right now or wait?
<headius>
if it uses it now it will be three deep to get at k/v
<enebo>
I was thinking in AST assocs use more memory than we need
<enebo>
from instr?
<enebo>
Hash -> Pair -> Key/Value
<enebo>
ah
<headius>
actually what do I care about KVP...I'll just make HashPair aggregate key and value right now
<headius>
you can do whatever you want with AST later
<enebo>
headius: yeah that’s what I meant
<headius>
and then Hash will aggregate HashPair
<headius>
ok
<headius>
can do
<enebo>
headius: I will unify/change so we do not have two pair classes later
<enebo>
headius: all in the guise of memory reduction in AST
<headius>
yeah
<headius>
I can't pass it through to IR anyway so it's just for you
<headius>
heh, HashPair.retrieve could return a RubyHash.HashNode :-D
<headius>
seems like a bad idea
<headius>
I love a good bad idea
<enebo>
fwiw I don’t think HashNode was a major memory user in profiling in Rails
<enebo>
surprisingly
<enebo>
but I have been trying to kill off ArrayList usage in AST
camlow32_ has quit [Remote host closed the connection]
tcrawley is now known as tcrawley-away
brauliobo has joined #jruby
<headius>
well, this will shrink it a bit anyway
<headius>
retained size might have been harder to see
<yopp>
and what's making me think about race, is the fact that when first request fails, next time rails processes same request just fine
<yopp>
all the time
<yopp>
with 9.0.1.0 on current master
<yopp>
simple counter helps
<enebo>
yopp: file an issue with us. This could also be something we are doing wrong with zsuper too (it would not be the first time on the 9k code base)
<yopp>
oppsie, currrent /rails/ master
<enebo>
yopp: the fact it is all the time makes that a more distinct possibility
<enebo>
yopp: you mean soon to be Rails 5
<yopp>
all the time, but for the first request
<enebo>
yopp: possibly something autoloads or something and second request has a different inheritance hierarchy or something like that
<yopp>
with second request but breaks with the same "Stackoverflow" in other place. But third request is going just fine
<yopp>
yeah, autoload or similar
<yopp>
okay, I'll drop an issue on jruby, and on rails
<enebo>
yopp: thanks. since they are puttnig out a release some time this year we should probably work :)
<yopp>
yeah, I was hoping to help with testing rails 5 on jruby, but since there no pg support, we will stick with 4.2 for a while. But maybe we will try with other app
<enebo>
cool
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub163>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/vZFo9
<GitHub163>
jruby/master 89a12f7 Kevin Menard: [Truffle] Untagged a bunch of passing StringIO specs.
<GitHub163>
jruby/master 4d34e0d Kevin Menard: [Truffle] Untagged more passing library specs.
<yopp>
yeah, I've added a mutex, and put that method body inside synchronize, and now it's working just fine
<enebo>
yopp: so you are saying this is only happening with some things loaded or an empty Rails metal app?
brauliobo has quit [Ping timeout: 250 seconds]
bb010g has quit [Quit: Connection closed for inactivity]
<enebo>
yopp: if you are hitting it doing something simpler than using an external gem which hits an external resource then that would probably make understanding the issue easier
<headius>
I officially hate that rvm switches to the ruby you just installed
<headius>
that's wrong
<enebo>
heh
<enebo>
yeah
<havenwood>
speaking of RVM, we haven't done a release :( will poke folk today
<yopp>
headius, is there any easy way to check where exactly super will be called?
<yopp>
inheritance chain is pretty big there
<headius>
well this extends ActiveController::Base doesn't it? I'd start there
<headius>
otherwise I guess you would check .ancestors in there and sort out which hierarchy it is and narrow there
<yopp>
yeah, but there like 30 ancestors
<yopp>
but okay, I have an idea
colinsurprenant has quit [Quit: colinsurprenant]
<yopp>
why there no Method#super_ancestors
<yopp>
or something like thos
<yopp>
•this
enebo has quit [Quit: enebo]
shellac has quit [Quit: Computer has gone to sleep.]
subbu has quit [Ping timeout: 255 seconds]
<GitHub132>
[jruby] tdaitx opened pull request #3331: Fix 3303 refactor zoneHelper into getRubyTimeZoneName (master...fix-3303-refactor-get-rubytime-tz-name) http://git.io/vZFj1
<GitHub18>
[jruby] tdaitx closed pull request #3309: get zone from RubyTime (fixes #3303) (master...fix-3303-use-rubytime) http://git.io/vGbyD
nateberkopec has quit [Ping timeout: 268 seconds]
Aethenelle has quit [Quit: Aethenelle]
temporalfox has joined #jruby
temporal_ has quit [Read error: Connection reset by peer]
subbu has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
<yopp>
uh
<yopp>
so, self.inherited super will be resolved using singleton class ancestors chain, right?
cristianrasch has quit [Quit: Leaving]
<yopp>
so if we will do something like "method(:inherited).super_method" inside Metal singleton class, we will get method that will be hit by the super. But thing is: there nothing to hit, so likely Kernel/Module implementation of the inherited is called by the super
skade has quit [Quit: Computer has gone to sleep.]