cultureulterior1 has quit [Ping timeout: 240 seconds]
_dabradley has joined #jruby
ludyte has quit [Quit: ludyte]
zorak8 has joined #jruby
vyorkin has joined #jruby
zorak8 has quit [Ping timeout: 260 seconds]
marr has quit [Ping timeout: 256 seconds]
zorak8 has joined #jruby
elux has quit [Quit: Leaving...]
ludyte has joined #jruby
Scorchin has joined #jruby
bruceadams has joined #jruby
asarih has joined #jruby
zorak8 has quit [Ping timeout: 256 seconds]
n1ftyn8 has joined #jruby
zorak8 has joined #jruby
yfeldblum has quit [Ping timeout: 255 seconds]
GregMefford has joined #jruby
cpuguy83 has joined #jruby
gazarsgo has joined #jruby
joelmheim_ has joined #jruby
chrisseaton has joined #jruby
calavera has joined #jruby
vyorkin has quit [Quit: WeeChat 1.0.1]
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 245 seconds]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 4 new commits to master: http://git.io/_YvB9g
<JRubyGithub>
jruby/master 7cfbcfd Chris Seaton: [Truffle] Get rid of the copy of options stored in RubyContext....
<JRubyGithub>
jruby/master 5257211 Chris Seaton: [Truffle] Remove visibility asserts - a mess, and don't always make sense in multi-language environment.
<JRubyGithub>
jruby/master f72ddfa Chris Seaton: [Truffle] Change the generic dispatch node from caching to looking up every time....
JRubyGithub has left #jruby [#jruby]
cultureulterior1 has joined #jruby
e_dub has quit [Quit: ZZZzzz…]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/OcBcNg
<JRubyGithub>
jruby/master 5bf8d52 Chris Seaton: Remove some lexer and parser functionality that has been long deprecated.
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/4fm60w
<JRubyGithub>
jruby/master 43c0df9 Chris Seaton: Fix another source refactoring bug.
JRubyGithub has left #jruby [#jruby]
<chrisseaton>
enebo: there's actually another parsing bug in -Ptest at the moment, but that was there before I started fiddling with the parser
<enebo>
chrisseaton: If it involved END block in method I know about it and will fix it tomorrow
<enebo>
chrisseaton: Although I don’t think that is actually a parser bug
<chrisseaton>
chrisseaton: yeah that was it
thsig has joined #jruby
thsig_ has joined #jruby
thsig has quit [Ping timeout: 256 seconds]
<headius>
man, busy busy aren't we
<headius>
chrisseaton: Arity is a broken abstraction
yfeldblum has joined #jruby
<headius>
it used to be fine to have a single integer to represent signatures, but they've gotten much more complex since 1.6
<headius>
(Ruby 1.6)
<chrisseaton>
headius: I've expanded Truffle's to be a tuple (required,optional,allowsMore), which seems to work very well
<headius>
yeah, that's what we need to do, and now's the time to do it
<headius>
it was very hard to remove it from everything before the new runtime
<chrisseaton>
does JRuby do full keyword arguments?
<enebo>
chrisseaton: we do except for zsuper
<enebo>
chrisseaton: and we have another open issue on them but we have them
<chrisseaton>
I think Zippy (Python on Truffle) has them - and they also have very sophisticated generators we might want to use to do something at some point
<headius>
that would be interesting
yfeldblum has quit [Ping timeout: 258 seconds]
<chrisseaton>
that works like goto does in C - compile multiple entry points into the same function
<headius>
with the new runtime it should be possible for me to pass kwargs through without a hash...I know you are probably able to escape them away
<headius>
yeah, that's the next step for IR
<headius>
I added very basic fixed-arity pass through so it's at the level of the old JIT
<headius>
we can make that N-arity pretty easy
* rtyler
waves
<headius>
rtyler: you hacking on a Sunday too?
<rtyler>
yes!
<headius>
what a world
Hobogrammer has joined #jruby
<enebo>
I also hope we can do something where we do not need to make a hash to use kwargs but I find kwargs to be designed around being a hash. I think there are probably a lot of unintended side-effects in the design
<rtyler>
making up for lost time at the end of the week :D
<headius>
I'm more playing PS3 than hacking, but I'm chatting during down times :-D
<headius>
enebo: I assume you expect that END block failure
<ghadishayban>
wondering in relation to that thread & the "Inlining Problem" that cliff click mentions. from what I gather, JVM will treat the block as a virtual call and not inline across it, no?
<headius>
ohh I see, in the context of that thread
<headius>
yes, in general any method that received a block will receive N of them, likely preventing any from inlining
<headius>
or perhaps the first couple might get some inlining treatment
<headius>
that's not fixed in any current JVM as far as I know
<rtyler>
after I finish this pull request cleanup, I think I'm going to get back to hacking on FFI; I want a JRuby-based window manager damnit
<ghadishayban>
I don't follow but the broadest changes to JRuby impl, just wondering whether that scenario is specially handled
<enebo>
headius: yes
<headius>
in JRuby, we are hoping to work around this by emitting the target method multiple times... so if we see two different calls to Array#each, they could get their own copies of Array#each that the JVM can inline through
<enebo>
headius: It was what we were talking about an hour ago
<headius>
enebo: ok
<chrisseaton>
not to bang on about Truffle but it's relevant here - we solve that yield problem by having no way to call a method or yielding apart from having a full proper call site with caching and inlining, including in core methods like Array#each. So there's no .call method on our blocks - you must use a proper call site.
<headius>
chrisseaton: that isn't really any different on JVM, because they're all call sites
<headius>
what's different is that since it's not dynamic, we just make it a virtual call and let the JVM do what it does for virtual calls
<headius>
the missing piece is that hotspot can't see a monomorphic path through an intermediate call, so it never specializes the block back to its home...I would assume Truffle causes the intermediate method to get specialized in the same way we want to
ludyte has joined #jruby
<chrisseaton>
yeah - the problem is operational - how hotspot is implemented - rather than theoretical
<headius>
indeed
<chrisseaton>
yeah, the term we use for that specialisation is splitting - we split the method into multiple copies if it's used in a different way such as different blocks
<headius>
right, that's exactly what we intend to do in IR
<headius>
the inlining aspect of it was functional as a prototype...we need to expand that to arity splitting, type profile splitting, block specialization...it's all doable given time
<ghadishayban>
appreciate the dialogue. (this comes up pervasively in Clojure for higher order functions and combinators)
<enebo>
and IR can do it right now (sans some bit rot) and a profiling mechanism to determine when to do it (bigger problem I think)
<headius>
ghadishayban: oh, I'm sure it does...and it's going to be a big sore spot in Java now that lambdas are taking off
<chrisseaton>
...but how can you produce multiple copies of a core library method implemented in Java?
<headius>
chrisseaton: worst case, we re-emit that method as a synthetic class
<headius>
but we'd be moving block-receiving methods to Ruby for this
zorak8 has joined #jruby
<headius>
or have a second Ruby version that we can work with in IR
<enebo>
chrisseaton: we wlll least be changing Enumerable to be in Ruby so we can go that route quite a bit
<headius>
enumerable's easy enough because most of the methods are simple
<headius>
if method handles were up to the task, some of these could simply be handle-driven and hotspot would specialize from there...some day
elux has joined #jruby
<headius>
I so wish method handles had backward branch
<headius>
ghadishayban: feel free to ping me with any other questions: headius@headius.com
<ghadishayban>
backward branch?
<headius>
ghadishayban: there's no way to do a loop with MethodHandles alone
<headius>
they only flow forward
<ghadishayban>
I see
<chrisseaton>
headius: I haven't asked you this yet - what do you make of Nashorn's proposed abstraction of their internals into a dynamic language framework?
<headius>
I'd love to see such a framework, and I have no idea if what they have is the right place to start or not
<headius>
it sure sounds like it does a lot, but I'm also waiting for the announcement that what they have is beating V8
<chrisseaton>
I think one potential risk is that it is accidentally very JS specific in some way
<headius>
for sure
<headius>
I wouldn't claim I could generalize any of my call sites for other languages
<headius>
the specializable bytecode Remi has talked about would be a better place to start, maybe
<enebo>
chrisseaton: Difficult to make a general framework without doing to a few individual ones
<headius>
turn aload and iload and dload into just "load" and then have a framework that can give you that same bytecode with N primitive types
<headius>
our position, for our own sanity, is that we'll do what we can to accommodate the JVM, but the JVM needs to move faster on keeping up with us
<headius>
e.g. we have not done our own specialization because the JVM should...have not done our own escape analysis because the JVM should
<chrisseaton>
headius: another problem - I don't see it does anything for complicated frame and stack manipulation, which is key for Ruby
<chrisseaton>
if you still have to either allocate stacks on the heap or manually try to escape analyst them yourself in a custom IR, then it might not be enough
<headius>
yeah, that's a big pain for us...probably the biggest reason we decided we needed to explore our own IR
yfeldblum has joined #jruby
<headius>
chrisseaton: I'd actually be interested in seeing how far a JVM bytecode backend for Truffle could go
<headius>
you're gathering all the information we'd like to see...and there's ways to do almost of this above the level of JVM bytecode if the JVM doesn't do it for us below
yfeldblum has quit [Ping timeout: 265 seconds]
mister_solo has joined #jruby
enebo has quit [Quit: enebo]
mister_solo has quit [Client Quit]
<chrisseaton>
yeah, sort of thing a masters student at JKU would be ideal for - think they're starting sometime soon
skade has joined #jruby
<headius>
very cool...feel free to put them in contact with me if it happens
<chrisseaton>
btw Nashorn faster than V8 on one benchmark - mandelbrot (they're saying 'as fast as' but for me it's faster)
thsig_ has quit [Remote host closed the connection]
<chrisseaton>
the reason for this is interesting - if you are reasonably good everything goes away and the problem reduces to instruction selection, scheduling and register allocation
<chrisseaton>
which of course the JVM is very good at, and V8 is more basic on
<chrisseaton>
so the JVM wins!
ghadishayban has joined #jruby
<headius>
just takes a lot of wrestling to get there :-)
zorak8 has quit [Ping timeout: 258 seconds]
zorak8 has joined #jruby
mister_solo has joined #jruby
mister_solo has quit [Client Quit]
mister_solo has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] jrubyci pushed 1 new commit to master: http://git.io/E2LXXg
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master 1a93885 Chris Seaton: Tests for new detailed source positions.
ludyte has quit [Quit: ludyte]
thsig has joined #jruby
ludyte has joined #jruby
yfeldblum has joined #jruby
thsig has quit [Ping timeout: 260 seconds]
zorak8 has quit [Ping timeout: 260 seconds]
yfeldblum has quit [Ping timeout: 255 seconds]
marr has joined #jruby
JohnBat26 has joined #jruby
ghadishayban has quit [Ping timeout: 265 seconds]
e_dub has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
ghadishayban has joined #jruby
<chrisseaton>
Do I need to worry about JRuby's Java test suite (core/src/test) being run in parallel? Can I modify shared state in setUp()?
Aethenelle has joined #jruby
thsig has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
rtyler: I would say the biggest problem here is __typedeaf_varstack__ - is that a global?
<rtyler>
chrisseaton: thread and instance local
<rtyler>
Thread local associated with the objkect instance
<chrisseaton>
rtyler: no compiler technology we have today is going to optimise that away
* rtyler
nods
<rtyler>
still hunting for low-hanging fruit to optimize out
<chrisseaton>
why do you need thread local? everything else looks like Truffle could optimise it
<rtyler>
if to make calls to typedeaf methods across threads safe
<rtyler>
s/if/it's/
<chrisseaton>
yeah - but I mean what data structure needs to be stored in shared state rather than just being on the stack?
<rtyler>
it's gotta hold the variable stack so #method_missing magic will work inside the executed block
<rtyler>
which is specific to the instance, but I didn't want to just add an instance variable which would require synchronization across threads
<rtyler>
if I can get this down to something like 2x the overhead of a method call, I'll be happy
<chrisseaton>
I've read the comments but I still don't follow what you're storing in your stack - why does method_missing return some value instead of calling another method?
<rtyler>
chrisseaton: it's a hack to get around the inability to inject local variables inside of a block
<rtyler>
mutating a block's binding doesn't work in an obvious way
zorak8 has joined #jruby
<chrisseaton>
that link is dead already after 3 days!
<chrisseaton>
the link in the commit message I mean
<rtyler>
remove the >
<chrisseaton>
rtyler: is this just for the parameters?
<rtyler>
no, I'm actually ripping the use of the varstack for storing params right now
<rtyler>
it's much more for the variables
<chrisseaton>
but if you're defining methods the only locals you could capture are going to be the locals in the class or module body aren't they? are they pretty rare?
digitalextremist has joined #jruby
<rtyler>
chrisseaton: I'm holding onto the arguments passed in on method invocation, so the method_missing hook can emulate "local variables" inside the block
<rtyler>
l.log('message') -> inserts "message" into varstack -> block references `message` -> method_missing hook digs up `message` from varstack
<rtyler>
er, l.log('hello world') would be more clear
<chrisseaton>
you can't modify a binding then, could you synthesize one - using eval maybe
<rtyler>
tried that too, wasn't able to inject a new binding into the block's evaluation :(
<chrisseaton>
yeah... I suppose there is never going to be a solution to that because Ruby has already parsed the locals as method calls - so a new binding wouldn't help
<rtyler>
I wish there was a richer way to dynamically compose method objects, but then again, method objects would have to be first class citizens
* rtyler
longs for some of Python's design choices
<chrisseaton>
your problem is that you have to define the method_missing in a shared space - what about creating an intermediate object with a new method_missing that you just use for the call you're making
<chrisseaton>
instead of pushing to a shared state, use a new object with a new method_missing to do your call
<rtyler>
I'm not sure I follow how that would be different than the thread+instance local I'm making now, which is admittedly fugly
<chrisseaton>
I don't really know your application, but you currently do instance_exec in the actual instance. you could instead create a new object, with a singleton method_missing, that somehow defers everything else to the original instance, and instance_exec in that?
<rtyler>
I don't really have an application, I'm just experimenting with madness here :)
<chrisseaton>
well, application/gem
<rtyler>
heh, apparently using a Hash as a stack instead of Array is 1000x slower