yfeldblum has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
prasunanand has joined #jruby
<GitHub121>
[jruby] eregon pushed 2 new commits to truffle-head: https://git.io/vinpv
<GitHub121>
jruby/truffle-head 1dc8c8e Benoit Daloze: [Truffle] Fix semantics for Kernel#public_send....
<GitHub121>
jruby/truffle-head 157321f Benoit Daloze: Add convenience test methods for all values of Visibility
thedarkone2 has quit [Quit: thedarkone2]
donV has joined #jruby
tenderlove has joined #jruby
tenderlove has joined #jruby
donV has quit [Quit: donV]
bga57 has quit [Ping timeout: 250 seconds]
bga57 has joined #jruby
raeoks has joined #jruby
enebo has joined #jruby
knu has quit [Quit: Reboot...]
knu has joined #jruby
nowhereFast has joined #jruby
prasunanand has quit [Ping timeout: 244 seconds]
claudiuinberlin has joined #jruby
pawnbox has quit [Remote host closed the connection]
yfeldblum has quit [Ping timeout: 250 seconds]
prasunanand has joined #jruby
pawnbox has joined #jruby
<GitHub114>
[jruby] ssteidte opened issue #4141: IRB: arrow keys to move along cmd line and up/down in history not working on Windows https://git.io/vicII
yfeldblum has joined #jruby
blaxter has joined #jruby
blaxter has quit [Client Quit]
yfeldblum has quit [Quit: Leaving...]
vtunka has joined #jruby
shellac has joined #jruby
rsim has joined #jruby
jimbaker has quit [Ping timeout: 240 seconds]
jimbaker has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
pawnbox has quit [Remote host closed the connection]
drbobbeaty has joined #jruby
pawnbox has joined #jruby
enebo has quit [Quit: enebo]
pawnbox has quit [Ping timeout: 265 seconds]
<GitHub14>
[jruby] helle opened issue #4142: Leaking Classes since JRuby-9.1.x.x https://git.io/vicGx
pawnbox has joined #jruby
rsim has quit [Quit: Leaving.]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
tenderlove has quit [Ping timeout: 250 seconds]
Specialist has joined #jruby
tenderlove has joined #jruby
tenderlove has joined #jruby
tenderlove has quit [Remote host closed the connection]
prasunanand has quit [Quit: Leaving]
Puffball has quit [Remote host closed the connection]
prasunanand has joined #jruby
Puffball has joined #jruby
Puffball has quit [Remote host closed the connection]
Puffball has joined #jruby
Puffball has quit [Remote host closed the connection]
prasunanand has quit [Ping timeout: 276 seconds]
Puffball has joined #jruby
drbobbeaty has joined #jruby
prasunanand has joined #jruby
bbrowning has quit [Quit: Leaving]
bbrowning has joined #jruby
bbrowning has quit [Ping timeout: 265 seconds]
bbrowning has joined #jruby
prasunanand has quit [Remote host closed the connection]
enebo has joined #jruby
dinfuehr_ has joined #jruby
dinfueh__ has quit [Ping timeout: 244 seconds]
donV has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<headius>
chrisseaton: hey, we haven't talked about refinements much
<headius>
some ruby-core folks are starting to push for dynamic refinements again
<headius>
instance_eval(using: Foo, &block)
<headius>
code in block gets dynamically refined each call to instance_eval
<chrisseaton>
headius: yeah, it's on our todo list but quite far down
<headius>
how will it impact your stuff if a given piece of code could have its method lookup path change from call to call, potentially across threads?
<headius>
this is basically dynamically-scoped method lookup
<chrisseaton>
Worst case we'd deoptimise and handle it in the interpreter - we can have a global dynamic-refinements-never-used to not have an impact if it's never used
<chrisseaton>
a global dynamic-refinements-never-used *assumption*, I mean
<headius>
sure, we can do that too...but if they're ever used it would mean every block in the system could have refinements applied at any time
<chrisseaton>
I'd have to have a proper think about it to see what all the implications were
<chrisseaton>
I don't really understand the current lexical refinements yet
<headius>
it's so frustrating... MRI barely optimizes any of this stuff, so when they introduce a feature like this they say "it doesn't slow us down!"
<headius>
yeah, of course it doesn't...you're already really slow
<headius>
lexical refinements now allow us to decide that certain call sites will never be refined, so they can have simpler guards that don't change every time they're called
<chrisseaton>
Maybe I could split refined and non-refined code paths?
<headius>
it would be good for you to look at this sooner rather than later, because if I can't convince them this is going to be in 2.4
<chrisseaton>
So the problem is you could have a single call site, in a method, receiving identically the same receiver, but the method you need to call is different?
<headius>
splitting the code paths might work to separate them...but you still have method lookup path changing across threads along the refined side
<headius>
chrisseaton: not just self calls either... instance_eval(using: Foo) { 1 + 1 } would have to check per-thread structure every time + is called to see if a refinement had been activated
<chrisseaton>
Maybe you could pass a hidden extra argument to all methods - a token that says whether there are dynamic refinements for this thread?
<headius>
consuming another stack slot or register for every call?
<chrisseaton>
Yeah - might not be the end of the world
<chrisseaton>
Not zero overhead
<headius>
introducing a new boolean that every method has to branch on before executing
<chrisseaton>
Well hopefully not branch on, but yes
<chrisseaton>
As I say I'll have a think - maybe it's do-able
<headius>
I'd rather it not be doable in the end because I think it's a bad feature to begin with
<headius>
just trying to gather up impact now
<chrisseaton>
I see what you mean, but I'm very cautious about being seen to criticise new features because they're bad for JRuby+Truffle
<headius>
right...I can't make a case solely based on JRuby
<chrisseaton>
Ultimately you could de-opt when the refinement is activated, de-opt again when it's not needed, and then check thread-local once per thread, which is only a register read anyway, so you could support it with reasonable performance
<headius>
it might defeat a class of optimizations forever, but because that's not even on their radar they don't consider it
<chrisseaton>
But 'reasonable' could be pretty bad if people run with this enabled all the time
<chrisseaton>
Possibly because some gem used by some other gem that people don't even remember using thinks it's a good idea to have some code always using dynamic refinements
<headius>
that's probably my biggest concern as a language feature...every block in the system is now suspect
<chrisseaton>
Maybe you could show how it breaks their new de-opt experiment?
<headius>
you will never be able to look at a block of code and know what it's going to call
<chrisseaton>
Talk about their code rather than hours
<headius>
hmm yes, perhaps
<headius>
it's hard to talk about impact to their code because they pay full price every time
<chrisseaton>
Matz has specifically invited discussion of performance implications though, so maybe I have more of a right to talk about it
thedarkone2 has quit [Quit: thedarkone2]
donV has quit [Quit: donV]
<headius>
it might help...I try to explain but when they don't even do inlining optimizations it's hard to find common ground
<headius>
I might try to prototype the separate refined call path today
<chrisseaton>
Hey I know - you could cache by (receiver, thread-id) instead of just receiver
<chrisseaton>
You'd only read the thread-id once per method, and it's just a method anyway
<chrisseaton>
And have a global assumption for any refinements active - if they aren't don't use the thread-id anyway
<headius>
yeah that would be easier splitting the execution paths
<headius>
unfortunately it also looks like their impl could change active refinements for a given block while it's currently executing
<headius>
I don't think it's safe across threads
claudiuinberlin has joined #jruby
zacts has joined #jruby
nicksieger has joined #jruby
johnsonch_afk is now known as johnsonch
nicksieger has quit [Remote host closed the connection]
nicksieger has joined #jruby
<headius>
thread isolation may be the killer here
<headius>
same block, two threads want to refine it differently, but there's only one collection of refinements
<chrisseaton>
But if you're caching the lookup can be slow path
<headius>
oh sure, it's not as much a perf concern as it is a feature concern
<headius>
you'd also have to assume any call might have to go slow path if another thread activates refinements
<headius>
but the feature concern is greater...two threads attempting to instance_eval(using: ...) at the same time will have unpredictable results
<chrisseaton>
I don't understand - doesn't each instance_eval apply just to the current thread?
<chrisseaton>
And just for the code executed inside the eval?
<kares>
MRI style process daemonization is mostly a headache with reopening files etc.
shellac has joined #jruby
vtunka has quit [Quit: Leaving]
Specialist has joined #jruby
bbrowning has joined #jruby
<chrisseaton>
Who's special about a daemon? Isn't it just a process not connected to a terminal?
camlow321 has joined #jruby
camlow321 has quit [Client Quit]
camlow325 has quit [Ping timeout: 240 seconds]
nowhereFast has quit [Quit: Bye]
<nomercy>
yeah, but it would be creat to have process management
<nomercy>
*great
<nomercy>
kares, ty
shellac has quit [Quit: Leaving]
<chrisseaton>
headius: I still don't understand your threading concern - each thread changes method lookup only on its own thread - how can the threads effect each other in your example?
<chrisseaton>
If you do instance_eval(using:, the refinements are only active for the block you pass, on that current thread, surely?
claudiuinberlin has quit []
Specialist has quit [Ping timeout: 255 seconds]
zacts has quit [Quit: WeeChat 1.4]
prasunanand has quit [Ping timeout: 244 seconds]
camlow325 has joined #jruby
Specialist has joined #jruby
subbu is now known as subbu|busy
camlow325 has quit [Quit: WeeChat 1.5]
claudiuinberlin has joined #jruby
<kares>
nomercy: maybe I do not understand what better process management is there than unixy scripts
<kares>
there are java options such but pieces such as Ruby daemons need to re-open file handles etc.
<kares>
stuff like that won't go well on JRuby ... since you do not want to turn on ObjectSpace
<nomercy>
i mean, what will happen if i cast kill -15 to jruby java process?
<nomercy>
i need some handler, which will interact to SIGTERM, and other stuff
claudiuinberlin has quit [Remote host closed the connection]
rcvalle has joined #jruby
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
subbu|busy is now known as subbu
claudiuinberlin has quit [Remote host closed the connection]
Specialist has quit [Ping timeout: 250 seconds]
claudiuinberlin has joined #jruby
nicksieger has quit [Remote host closed the connection]
Specialist has joined #jruby
nicoulaj has joined #jruby
zacts has joined #jruby
zacts has quit [Quit: WeeChat 1.4]
subbu is now known as subbu|lunch
nicksieger has joined #jruby
<kares>
nomercy: yes there are java wrappers - if that is smt your into. e.g. Tomcat has its own way and so does mostly each Java server
<kares>
foreman should be able to generate unix service scripts for you (although haven't tried with JRuby)
johnsonch is now known as johnsonch_afk
dinfuehr_ has quit [Remote host closed the connection]
circ-user-xG5o4 has joined #jruby
circ-user-xG5o4 has left #jruby [#jruby]
nicksieger has quit [Remote host closed the connection]
mtoy has joined #jruby
dinfuehr_ has joined #jruby
nicksieger has joined #jruby
nicksieger has quit [Remote host closed the connection]
zacts has joined #jruby
thedarkone2 has joined #jruby
Specialist has quit [Ping timeout: 255 seconds]
subbu|lunch is now known as subbu
nicksieger has joined #jruby
Specialist has joined #jruby
nicksieger has quit [Remote host closed the connection]
nicksieger has joined #jruby
Specialist has quit [Ping timeout: 255 seconds]
johnsonch_afk is now known as johnsonch
zacts has quit [Quit: WeeChat 1.4]
zacts has joined #jruby
pawnbox has quit [Remote host closed the connection]
claudiuinberlin has quit []
pawnbox has joined #jruby
bbrowning is now known as bbrowning_away
dinfuehr_ has quit [Remote host closed the connection]
camlow325 has joined #jruby
temporalfox has quit [Ping timeout: 244 seconds]
temporalfox has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nicoulaj has quit [Remote host closed the connection]
nicksieger has quit [Remote host closed the connection]
enebo has joined #jruby
<mtoy>
i have sat here all day, afraid to ask a question, but feeling like i have courage to look for my answers because this chat window is open. thanks for your help, i am solving my problems and you were awesome.
<lopex>
dont ever be afraid
<lopex>
and never hesitate to ask
lanceball is now known as lance|afk
camlow325 has quit [Ping timeout: 240 seconds]
pawnbox has quit [Ping timeout: 276 seconds]
tenderlove has joined #jruby
camlow325 has joined #jruby
<headius>
mtoy: chrisseaton Refinements are local to the scope, not the thread
<headius>
oops, that's just for chrisseaton
<headius>
and the way this new feature is implemented shares a refinements collection with the parent scope
<headius>
so two threads doing instance_eval(using: ... will both try to apply their refinements to the same scope
<chrisseaton>
headius: are you sure that's still the case here? That would be really un-intuitive
<headius>
did you look at the impl?
<chrisseaton>
No, not yet
<headius>
well, unless I'm reading it wrong, it shares the refinements
<headius>
prev_cref is the parent scope...they get refinements out of that and reuse them in the new cref created for each instance_eval
<chrisseaton>
So it's sort of as if there's a local variable saying what refinements to use? And when both threads run the block they race to set that variable?
<headius>
that's right
<chrisseaton>
I see
<headius>
local variable...not so much, more like a lexical-scope variable
<lopex>
but you can refine at any place in ruby right ?
<headius>
but that's an artifact of MRI's impl (and JRuby's, largely, since we mimic most of their structure)
<chrisseaton>
Yeah, eregon implemented all that complex local variable scope for me so I don't know much about it
<headius>
lopex: you can only refine at toplevel or class level right now
<lopex>
ah
<headius>
a proposal for Ruby 2.4 would allow you to specify using as an option to instance_eval, and whatever block is given to instance_eval would then act refined