rusk has quit [Read error: Connection reset by peer]
<headius[m]>
kares awesome
rusk has joined #jruby
<headius[m]>
I've known for a while we had hacks interfering with hacks but wasn't sure where to start unraveling it
<headius[m]>
I'd love to go pure Ruby with enumerable, but you can't represent all argument passing in pure Ruby
<kares[m]>
yep - lazy is still problematic but certainly not worse than it was
<kares[m]>
looking at rubinius impl atm ... seems were on par with them
<kares[m]>
I wonder if they pass all yielder + lazy specs
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
<headius[m]>
Yeah I believe everyone except MRI is running the same pure Ruby lazy enumerator based on Marc-André's backport lib
<headius[m]>
Which of course also has the same argument processing problems
sagax has quit [Remote host closed the connection]
lucasb has joined #jruby
<headius[m]>
Ok back to work
sagax has joined #jruby
<headius[m]>
I'm going to audit 9.2.8 bugs until I don't see anything I think I can fix for this release...at that point I'll go back and try to get my global vars patch better
<headius[m]>
oh kares...I think I saw a perf regression
<headius[m]>
numeric related
<kares[m]>
headius: ooh, that would be unexpected? did some micro-benchmarks and we were doing better
<kares[m]>
do you have any details?
<headius[m]>
yeah sorry got distracted
<headius[m]>
I was just benchmarking a loop without indy
<headius[m]>
that call path should probably pass both long and RubyFixnum so we're not constructing the fixnum all the time if it's not the method we think it is
<headius[m]>
but that's nothing new
<headius[m]>
kares: modifying both Lt and Plus sites to use isFixnumReopened does go back to 9.2.7 perf
<kares[m]>
yeah I got that far
<headius[m]>
a stupid fix would be to split isFixnumReopened into isFixnumPlusRedefined etc but obviously that's gross
<headius[m]>
I wish we had value types so CacheEntry would not have to be traversed
<headius[m]>
or some way to atomically cache the entry.ok and isBuiltin check all at once
<headius[m]>
hmm yeah...so indy gets around this by only binding the fast method if entry is ok and isBuiltin
lucasb has quit [Quit: Connection closed for inactivity]
Ryctolagus has joined #jruby
<Ryctolagus>
I am desperate search of an editor/IDE that is snappy like vim with MRI. My employer requires use of a windows work station and deployment, hence the migration to JRuby, any help is greatly appreaceated.
<kares[m]>
just install vim on win ... you have the linux sub-system in win 10
<enebo[m]>
vim and emacs work great on wsl on win 10
<Ryctolagus>
havenwood: trying to find that setting in rubymine.... this is why I stick to vim...
<Ryctolagus>
Anyone get jruby to work with vim on windows 7? MRI works like a charm and is snappy within vim.
<headius[m]>
JRuby should work fine on Win7+
<headius[m]>
we test a full (simple) Rails app on Windows before every release
<Ryctolagus>
Yes it does I just can't get Vim to see it with any of my standard Ruby plugins
<Ryctolagus>
JRuby running performant on windows is why we are going to it over MRI
<headius[m]>
Ah well that's more likely a problem with the Ruby plugins
<headius[m]>
FWIW I wouldn't recommend using JRuby as your vim Ruby plugin if that means it has to be firing off lots of subprocesses, because that will be pretty slow
<headius[m]>
if it's just about occasionally running code that should be fine
<Ryctolagus>
ah, that may be what I am encountering.
<headius[m]>
but like some people plug it in to do syntax checking every keypress or whatever
<headius[m]>
yeah we run well if the same process stays up for more than say 10 seconds, but constantly starting a new process will be slow every time
<headius[m]>
--dev will help
<headius[m]>
but not enough
<Ryctolagus>
semi new to the ruby community, it is bad juju to develop an application in MRI and deploy to JRuby?
<Ryctolagus>
I am assuming something could and would break
<headius[m]>
is this a single background rubocop process though?
<headius[m]>
if it's a long-running rubocop monitoring the dir the problem might be it's not using real filesystem events and is instead scanning dirs
<headius[m]>
which would explain a delay picking up changes
<Ryctolagus>
for the dev, yes it is a single background process.
<headius[m]>
I'm just brainstorming here...I don't know what your setup is
<Ryctolagus>
I am thankful for any advice here.
<headius[m]>
let's see what rubocop uses for monitoring...
<headius[m]>
depends on "wdm" for optimized monitoring on Windows
<Ryctolagus>
nice!
<headius[m]>
which is a C extension
<headius[m]>
so that's probably it
<headius[m]>
sigh
<headius[m]>
so listen will fall back on polling
<Ryctolagus>
I think I may be better off hacking on vim, at least I would be in familiar waters.
<headius[m]>
we need to make listen gem an adapter for JRuby (Java has a cross-platform filesystem event API already)
<headius[m]>
the journey never ends!
<Ryctolagus>
Windows is just a pita, there is no avoiding it.
<headius[m]>
yeah but this is great to know now
<headius[m]>
probably wouldn't be more than a few lines of Ruby to add effiicent filesystem monitoring for JRuby
<Ryctolagus>
woot!
<headius[m]>
huh where does MRI put its JIT output?
<havenwood>
headius[m]: /tmp
<havenwood>
headius[m]: (taking advantage of Linux treating that dir as in-mem)
<headius[m]>
I can't find anything there on macos
<headius[m]>
maybe I'm doing somethingwrong
<headius[m]>
I just wanted to see how big the .so for a trivial method is
<headius[m]>
you're on linux with a jit-enabled Ruby? Maybe you can try this and see if you can dig up the .so: ruby --jit -e 'def foo; 1 + 1; end; 100000000.times { foo }; sleep'
<headius[m]>
at first I tried running "gem list" but didn't get anything from that either
<havenwood>
headius[m]: --jit-save-temps keeps them paste execution
<havenwood>
past*
<headius[m]>
I tried to sleep but maybe it's culling them via GC or something
<headius[m]>
thanks I'll try that
<havenwood>
headius[m]: that flag should persist the .c .o .so files
<havenwood>
_ruby_mjit_p18322u101.{c,o,so}
<headius[m]>
is that the filenames you see in /tmp
<headius[m]>
I see no change...something's screwy here I guess