colinsurprenant has quit [Ping timeout: 265 seconds]
colinsurprenant_ is now known as colinsurprenant
<nirvdrum>
Regexp encoding still blows my mind. I'm sure there's some underlying consistency to it, but it eludes me.
<enebo>
nirvdrum: is this a real world problem or just trying to pass some specs?
<enebo>
nirvdrum: I just read the bug :)
<nirvdrum>
That's just something I came across while trying to understand the code. What I'm trying to do is make the Truffle Regexp implementation encoding-aware. I'm hoping to pull in from non-Truffle as much as possible.
<nirvdrum>
I was hitting a real mental hurdle yesterday and discovered that bug had a good part to do with it :-P
pjammer has joined #jruby
<enebo>
nirvdrum: but just solving this is not that hard is it?
<nirvdrum>
My current "wtf?" is Regexp#match doesn't use the underlying regex directly. It compiles a new one with a different encoding and matches with that.
<enebo>
nirvdrum: encoding() and source() in one case is always str.encoding and the other depends on wheter pattern has an encoding
<nirvdrum>
enebo: Fixing that bug shouldn't be too hard. But it's also not straightforward. My understanding of the code is other parts expect it to have the original encoding, not the regexp encoding.
<nirvdrum>
The cheap fix then is to keep track of a ByteList and an Encoding and deal with it on the source() call.
<nirvdrum>
enebo: Anyway, my current cognitive gap is with this: puts "à".match(/[[:alnum:]]/)
<nirvdrum>
The regexp literal's regex instance is US-ASCII.
<enebo>
nirvdrum: seems like str is the actual bytelist it came in as right? and pattern.encoding is the modifer + parsing simplifying it maybe?
<nirvdrum>
But the matcher fails with US-ASCII. So, in this case Regexp#match creates a new Regex with a UTF-8 encoding.
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
But given that's a completely different joni Regex, I have no idea what the semantics are supposed to be.
<nirvdrum>
enebo: str is the ByteList as it comes in. But in MRI, it also gets the negotiated encoding.
<enebo>
nirvdrum: this particular issue always confuses me and I never remember how it works about a week later
<enebo>
nirvdrum: once you go down that common path in RubyRegexp and you pass in out params of encodings
<nirvdrum>
I'm looking at MRI to get a better handle on it, but a lot of that is tucked into joni. And it's a bit complicated by JRuby's three tiers of Regex caching.
<enebo>
Mach 3 cache
subbu has joined #jruby
iamjarvo has joined #jruby
<nirvdrum>
It feels like this Regexp thing wasn't designed, but just sorta happened.
<nirvdrum>
(Not JRuby . . . Ruby's in general).
<enebo>
nirvdrum: yes…Ruby is very organic
<enebo>
nirvdrum: like include Foo.dup had to have been some weird afterthought
<nirvdrum>
And the problem with specs is I can certainly make them pass and have zero confidence I'm doing the right thing.
<enebo>
nirvdrum: yeah we have had passing specs just due to caching lining up
<enebo>
nirvdrum: our cache should be a cache of bytelist+encoding
<nirvdrum>
static final WeakValuedMap<ByteList, Regex> patternCache = new WeakValuedMap();
<nirvdrum>
static final WeakValuedMap<ByteList, Regex> quotedPatternCache = new WeakValuedMap();
<nirvdrum>
static final WeakValuedMap<ByteList, Regex> preprocessedPatternCache = new WeakValuedMap()
<nirvdrum>
As far as I can tell, the preprocessed cache is before the encoding is negotiated.
<nirvdrum>
patternCache is after negotiation.
<nirvdrum>
And I haven't worked up to quotedPatternCache yet.
<lopex>
nirvdrum: some of those caches might be dead now since last headius string work
<lopex>
nirvdrum: also, quoted cache might be a 1.8 remnant somewhat
<nirvdrum>
Yeah, it looks like it's only called from tests. I guess I'll just delete that.
<lopex>
nirvdrum: after reoptimization those might be reintroduced
<lopex>
on some form
<lopex>
*in
<nirvdrum>
Although headius wrote the test only 7 months ago.
<lopex>
nirvdrum: oh you mean only one cache is dead now ?
<nirvdrum>
Yes. The quotedPatternCache only seems to be referenced from a test.
<lopex>
nirvdrum: some of the future reoptz might need it
<nirvdrum>
lopex: What is a "quoted pattern"?
<lopex>
nirvdrum: a pattern after quoting (that comes from string)
<lopex>
nirvdrum: used by String#split/sub/gsub/scan etc
<nirvdrum>
Gotcha.
<nirvdrum>
Why would that have a separate cache though?
<lopex>
nirvdrum: since just like in java now, lots of String methods always used to go string -> regexp
<lopex>
nirvdrum: because of quoting - they would collide with non quoted oens
<nirvdrum>
It doesn't seem to be an LRU cache or anything.
<lopex>
*ones
<lopex>
nirvdrum: yeah, the caches were always disputed
<lopex>
well, the way they worked
<lopex>
on microbenches they shined though :)
camlow325 has joined #jruby
<nirvdrum>
lopex: Okay, so the idea is the quoted pattern cache is for the String ByteList before it's been quoted, rather than after?
<lopex>
nirvdrum: that's why they're weak
<lopex>
nirvdrum: yeah, to skip the whole preprocessing etc
<lopex>
also, joni regexps are quite costly on creation
<lopex>
nirvdrum: I guess, you might take a look at String before headius lastest work
<nirvdrum>
Eh, it's not a big deal. I'm just trying to wrap my head around all this.
<nirvdrum>
But I'd vote for removing that cache if it's not being used since it only serves to confuse at the moment.
rcvalle has joined #jruby
<lopex>
nirvdrum: well, lots of complications was also (or mostly) because I tried to commonalized some 1.8/1.9 logic
<nirvdrum>
That's not really my problem right now though. It's trying to figure out the semantics of match ;-)
<lopex>
nirvdrum: sure
<lopex>
nirvdrum: it should be reqritten now
<lopex>
*rewritten even
<lopex>
1.9/2.0 diff is not that big issue now
<lopex>
but former kcode/encoding bifurcation was painful
<lopex>
and kcode usage was not consistent even in plain 1.8 mode
vyorkin has quit [Quit: WeeChat 1.1.1]
<lopex>
nirvdrum: the kcode remnants is even visible in jcodings now in the Base* encodings
<lopex>
it was bad days
<nirvdrum>
I don't know how you did all this and remained sane.
<nirvdrum>
I almost put my fist through my monitor last night.
shellac has quit [Quit: Ex-Chat]
<nirvdrum>
lopex: Is there any reason there couldn't be a lightweight copy constructor for Regex? Then you could just update the encoding without have to re-init.
dinfuehr_ has quit [Remote host closed the connection]
mister_solo has quit [Ping timeout: 256 seconds]
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 244 seconds]
vtunka has quit [Quit: Leaving]
mrmargol_ has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
mrmargolis has quit [Ping timeout: 276 seconds]
colinsurprenant_ has joined #jruby
colinsurprenant has quit [Ping timeout: 255 seconds]
colinsurprenant has joined #jruby
palacz has quit [Ping timeout: 240 seconds]
drguildo has joined #jruby
<kares>
codefinger: excellent, thanks!
colinsurprenant_ has quit [Ping timeout: 264 seconds]
colinsurprenant_ has joined #jruby
colinsurprenant has quit [Ping timeout: 245 seconds]
colinsurprenant_ is now known as colinsurprenant
deobalds has joined #jruby
yfeldblum has joined #jruby
_JKL_ has quit [Remote host closed the connection]
<kares>
codefinger: lot of changes to support 9K ... noticed you won't use the same code base for 1.7 + 9K ?
tcrawley is now known as tcrawley-away
<codefinger>
kares: yea, i want to cut lots of stuff out (like 1.8 and 1.9 support). i think it's worth the effort to merge fixes back and forth. thoughts?
apofis has quit [Quit: This computer has gone to sleep]
<kares>
codefinger: sure whatever suits ... wanted to ask if there's any 9K feedback
<kares>
did not have time for jruby-rack thus although all seems to work under 9K I do not have a real-world feedbac
<codefinger>
kares: i
mrmargolis has joined #jruby
<codefinger>
kares: i've used it for some simple apps without trouble
<kares>
soundz as a good start :)
<codefinger>
i think we won't really know until after 9k is out... since one begets the other
<codefinger>
why plan when you can react! :)
colinsurprenant has quit [Quit: colinsurprenant]
<kares>
absolutely :) ... react is the new programming paradigm anyways!
<chrisseaton>
bbrowning: builds for me - you're on master, right? What environment are you building on
<bbrowning>
I'm on master, fedora 21, openjdk version "1.8.0_45"
gaustin has quit [Ping timeout: 245 seconds]
<bbrowning>
building via "./mvnw" as shown in BUILDING.md
<chrisseaton>
Travis seems happy but we don't have results from the latest commit yet
<chrisseaton>
Can you try a clean build?
<bbrowning>
hmm travis does "./mvnw -Pbootstrap clean install" - I'll try that
<bbrowning>
I think this is a clean build, but I can clone again if this doesn't work
camlow325 has joined #jruby
<chrisseaton>
I mean ./mvnw -Pclean clean, and then build again
<bbrowning>
just doing the travis command appears to have fixed things
colinsurprenant has joined #jruby
<bbrowning>
so whether it's the -Pbootstrap or the clean, it's working now :)
<chrisseaton>
Had you done -Pbootstrap before
<bbrowning>
no, but BUILDING.md doesn't say anything about needing it now
<bbrowning>
before mvnw I used to do -Pbootstrap
<bbrowning>
looks like it's still needed
<chrisseaton>
headius enebo: ^ another data point on people not understanding the bootstrap thing or the docs not being clear enough
sholden has joined #jruby
<chrisseaton>
not sure why that would cause Truffle to fail - did you control-c during a previous compile?
<bbrowning>
I don't think so - I can only guess I wasn't as clean as I thought I was
<bbrowning>
maybe had an old version in there somewhere
<nirvdrum>
mvnw uses a maven 3.3.x. It's possible that's treated as a completely new base and thus needed the bootstrap.
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yfeldblum has quit [Ping timeout: 256 seconds]
<sholden>
I’m trying to get a coworker set up with jruby, but she’s getting: ERROR: Loading command: install (OpenSSL::X509::StoreError) setting default path failed: Invalid keystore format
<sholden>
anyone know what may be causing that? I don’t have a ~/.keystore on my box but I’m not getting that exception
<sholden>
kinda flailing trying to fix troubleshoot this one =/
<nirvdrum>
sholden: Using an Oracle JDK build or OpenJDK?
iamjarvo has joined #jruby
<sholden>
oracle
<sholden>
sorry, got her back on screen hero so I can try stuff out
gaustin has joined #jruby
<nirvdrum>
No idea then. That should have the cacerts I believe.
vikaton has quit []
<chrisseaton>
sholden: do you have anything crazy in your environment variables?
mister_s_ has quit [Ping timeout: 256 seconds]
<chrisseaton>
No random crap in JRUBY_OPTS or JAVA_OPTS for example?
<sholden>
actually she answered oracle 1.8 after I had directed her to get latest jvm
<sholden>
before that I had her chekc jruby version and reported jruby 1.7.20 (2.0.0p598) 2015-05-04 3086e6a on Java HotSpot(TM) 64-Bit Server VM 1.7.0_10-b18 +jit [darwin-x86_64]
palacz has joined #jruby
<sholden>
this time I got “marshal data too short”
<chrisseaton>
That sounds like an application error
tcrawley-away is now known as tcrawley
<sholden>
as far as I can tell the only application is rubygems…
<sholden>
this is from “gem install bundler”
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
colinsurprenant_ has joined #jruby
colinsurprenant has quit [Ping timeout: 276 seconds]
colinsurprenant_ is now known as colinsurprenant
dinfuehr has joined #jruby
iamjarvo has joined #jruby
colinsurprenant_ has joined #jruby
colinsurprenant has quit [Ping timeout: 276 seconds]
dinfuehr has quit [Ping timeout: 264 seconds]
colinsurprenant_ has quit [Ping timeout: 256 seconds]
colinsurprenant has joined #jruby
camlow325 has quit [Remote host closed the connection]
palacz has quit [Quit: Leaving.]
camlow325 has joined #jruby
DomKM has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
camlow325 has quit [Remote host closed the connection]
x1337807x has joined #jruby
vikaton has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
tcrawley is now known as tcrawley-away
<bbrowning>
enebo: so I was able to reproduce an OOM locally by running rubocop in a loop - the 26th loop gave me an OOM, but with a different stack than travis hit
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
bb010g has quit [Quit: Connection closed for inactivity]
Aethenelle_ has joined #jruby
Aethenelle has quit [Read error: Connection reset by peer]
Aethenelle_ is now known as Aethenelle
<Aethenelle>
nirvdrum: that packer stuff I linked the other day may not be as advertised. I still need to try in my linux VM (which I left at home), but on OSX it's not working for armel. I'm having issues just booting debian outside of using packer...
<nirvdrum>
Thanks. I was going to take a look after I finish this regexp stuff.
<nirvdrum>
Assuming I don't die of a rage stroke before then.
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Aethenelle>
... You might want to wait on that till you've had some tea or something...
<Aethenelle>
I am working on a PR for packer to allow specifying the qemu-img args and another afterward to build w/ debootstrap.
<Aethenelle>
maybe I'll go extra crazy and make a chroot qemu user mode driver for vagrant...
bbrowning_away is now known as bbrowning
pjammer has joined #jruby
<bbrowning>
enebo: so definitely a hard-to-reproduce OOM here - running rubocop on TB4 in a loop I hit it on loop 26, loop 3, loop 17
<bbrowning>
I'll try to get a heap dump next
tcrawley-away is now known as tcrawley
<enebo>
bbrowning: very odd. Sort of sounds like we are leaking due to concurrency or something? Or insane allocation and we cannot keep up
<bbrowning>
I don't really know yet - I don't think rubocop does much in the way of concurrency
<bbrowning>
if any
<enebo>
bbrowning: I am hoping to see a zillion objects dominate your heap
<enebo>
zillion of the same objects
Aethenelle has quit [Ping timeout: 250 seconds]
rsim has quit [Quit: Leaving.]
vikaton has quit []
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
skade has joined #jruby
pietr0 has quit [Ping timeout: 252 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 3 new commits to master: http://git.io/vkpcL
<JRubyGithub>
jruby/master 9ea98e9 Charles Oliver Nutter: Return Enumerator self calling #each with no block. Fixes #3009.
<JRubyGithub>
jruby/master 864ce45 Charles Oliver Nutter: Add spec for Enumerator.new form calling bare each....
<JRubyGithub>
jruby/master 8641ab7 Charles Oliver Nutter: Untag passing Enumerator specs.
JRubyGithub has left #jruby [#jruby]
<bbrowning>
enebo: looks like a JIT thread has hundreds of MB of retained stuff
<bbrowning>
lots of org.jruby.org.objectweb.asm.Frame instances
<enebo>
bbrowning: fwiw I expect us to use more memory overall but I would not expect this JIT to be substantally larger than 1.7 JIT. We must be retaining a reference to something we can be dropping
<enebo>
bbrowning: first part of the statement is about retaining IR info second part if about bytecode generation via JIT
<bbrowning>
headius: ahh so just too big of a method and rubocop is using that for its code analysis
<headius>
bbrowning: yeah, so the change I'm playing with would inspect the method ahead of time and not try to compile if it's bigger than some threshold
<headius>
probably instruction count since one method with no flow control might not have many basic blocks
iamjarvo has joined #jruby
<chrisseaton>
I only see the lexer source - is the generated code online somewhere?
<headius>
it's in the gem at least...he must not version it
<headius>
I'm sure there's a rake target to generate it though
apofis has quit [Quit: This computer has gone to sleep]
<chrisseaton>
If it's lots of branches it all depends on how many of those branches you've exercised
apofis has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
<enebo>
which in the ruby lexer can be nearly all of it
<enebo>
but in any case we should be able to eventually generate synthetic methods for big methods
<chrisseaton>
might it not be the case that regular modern Ruby only exercises a small part of the grammar?
<bbrowning>
headius: oh I forgot to mention w/ -Xjit.background=false it keeps humming along
<chrisseaton>
does the IR do branch profiling?
<headius>
bbrowning: makes sense
<headius>
chrisseaton: IR does no profiling at all right now
<headius>
enebo: indeed...but in the short term I think insn count is a good bailout
<enebo>
headius: yeah either way should work
<headius>
target script needs to go through the same logic so that it can compile only the pieces needed
<headius>
running a script with a big method in it right now just blows up and doesn't run
<enebo>
chrisseaton: small part of the grammar but likely most of the lexer
<headius>
well no, it does run, but it will OOM before running
<headius>
that can be a separate fix though
<headius>
enebo: so this method is "only" 17936 instructions
<headius>
10000 may be too permissive for upper bound
<chrisseaton>
I like the goto emulation in this
<headius>
chrisseaton: :-\
<headius>
Ragel's parsers are crap when the language doesn't support goto
<chrisseaton>
When you get OOM compiling this, how much heap are you using?
<headius>
c-r-a-p-
<enebo>
headius: well this is also dependent on how much bytecode will be generated…which for exception handling will not line up well with instr count
<headius>
chrisseaton: default `jruby` heap of 500MB
<headius>
it's all ASM structures I'd wager...it's just too big
<headius>
enebo: sure, I'm open to suggestions here
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
I think we can estimate that N instructions will produce roughly N * X bytes of JVM bytecode given typical Ruby
<headius>
I'm saying 10k is probably not small enough because 17k required all of a 500MB heap to JIT
<chrisseaton>
is 500MB because of smaller VPS instances? it seems very low now
<headius>
it is low now, and apparently JVM 8+ does not cap heap like it used to
<headius>
we set this years ago because 4/5/6/7 had a deafult of 64MB on most systems
<headius>
but we can't tell if we're running on 4/5/6/7 versus 8
<headius>
at least not in time to change heap setting
<enebo>
BB # * weight1 + instr
<enebo>
hmmm
Aethenelle has joined #jruby
<enebo>
less than what I don’t know
<headius>
bbrowning: I think we have this in hand...if you could file an issue we'll come up with something
rsim has joined #jruby
<headius>
the OOM from compiling too-large methods is likely causing OOM elsewhere, so fixing this should fix the general issue
<chrisseaton>
does anyone know how I can minimally drive the advance method in a loop with some Ruby code as input?
<headius>
chrisseaton: minimally? no
<headius>
guess you could try to parse something and capture the inputs
<headius>
there's lexer state too though
<bbrowning>
headius: sure thing
<headius>
enebo: I'm inclined to just make it 1000 or 5000 and call it a day
<enebo>
headius: hmmm CFG.rescuerMap
<enebo>
headius: yeah for now let’s just solve it
<headius>
I'll set it to 1000 and try a test:mri:jit run to see how many methods fail
<enebo>
headius: perhaps run rails new or something and see if anything besides date/format
<headius>
seems a little small but then you have to guess the instructions will be 5-10 bytecodes each
<enebo>
actually date/format I think was spliced apart pretty good
<headius>
mmm sure
<headius>
sync JIT + this change should give me a good idea
<enebo>
headius: we could do the ASM thing and attach a cost value per instr to get better estimate
<enebo>
IRScope.estimateCost()
<enebo>
where it will examine number of rescues and ask each instr for its cost
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/vkhfa
<JRubyGithub>
jruby/master d03e6ef Kevin Menard: [Truffle] Removed dead code.
<JRubyGithub>
jruby/master 2148be1 Kevin Menard: [Truffle] Moved Regexp#options out to a Rubinius primitive.
JRubyGithub has left #jruby [#jruby]
<enebo>
It would not be perfect but we could probably get something which was pretty ok
<headius>
enebo: yeah, I might have to eyeball the JIT output because I don't know how to get incremental sizes from asm
<enebo>
headius: I only remember there was some feature
<headius>
it builds some data structure internally before emitting coe
<headius>
there is a size estimate but it's post-visit, pre-generate
<headius>
we blow up during visit
<enebo>
headius: but it sounds like we don’t want to use it for fear of OOM’ing :)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bbrowning opened issue #3016: OutOfMemoryError in 9k on code with very large methods http://git.io/vkhJU
JRubyGithub has left #jruby [#jruby]
<headius>
right
<enebo>
headius: anyways I just meant the idea
<headius>
yeah agreed
<enebo>
headius: does make me wonder if we can get remi to put asm on a diet
<headius>
imperator: I don't think we've ever pushed a gem
<imperator>
d'oh!
<headius>
and pg author doesn't seem interested
<imperator>
so...how are people using jruby/rails + postgres?
<nirvdrum>
Sequel.
<nirvdrum>
Or ActiveRecord-JDBC.
<headius>
Could not compile; passes run: []:TestDateParse.TestDateParse.test__parse at /Users/headius/projects/jruby/test/mri/date/test_date_parse.rb:5 because of: "Could not compile org.jruby.internal.runtime.methods.MixedModeIRMethod@3e4a20f9; instruction count 1527 exceeds threshold of 1000"
<headius>
heh, even date parsing TESTS are too big
<imperator>
Sequel has its own adapters?
<headius>
sequel uses jdbc directly on JRuby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 1 new commit to master: http://git.io/vkhmT
<JRubyGithub>
jruby/master df8b49a Benoit Daloze: [Truffle] Full Module#attr{,accessor,reader,writer}.
JRubyGithub has left #jruby [#jruby]
<enebo>
hmmm we might be able to reduce that one
<headius>
enebo: running MRI tests and I'm still only getting a handful failing, mostly < 2000 insns
<imperator>
headius, ok, thanks
<headius>
there's a few outliers
<enebo>
__LINE__ probably forces all these values to be assigned as temps before being put into the arrays
<jeremyevans>
Pure ruby drivers such as postgres-pr also work fine on JRuby, but most people using Sequel on JRuby are using JDBC
<headius>
2000 might be a good limit based on this
<imperator>
i wasn't sure what the status of postgres-pr was
<enebo>
oh wait that ends up as a fixnum
<enebo>
yeah amazing
<nirvdrum>
imperator: I had very good success with Rails + Sequel with Postgres. And you get all the other wonderful benefits of Sequel, too. Regular release schedule, optimizes incredibly well, real plugin API, etc.
<enebo>
Ah math is in there
<headius>
enebo: when test run complete's I'll gist a log of all failed methods
<headius>
-'
<enebo>
I would think all of this would be prop’d but I guess it is still building a massive tree of arrays in a single method
<headius>
indy bytecode counts will be smaller too
<chrisseaton>
Do you still have the 65k bytecode limit, or do you split into separate methods? As I guess this doesn't fit into 65k either
<headius>
chrisseaton: before this fix it would just go for it and let JVM verified kick it out
<headius>
but that allows methods that will never load to do stuff like this OOM
<enebo>
chrisseaton: we will be working to split out big methods into multiple methods at some point
<enebo>
headius: funny too because we were like so what it is offthread and async…let it fail
<headius>
I'll just blame you and keep my conscience clear
<enebo>
heh why not
<headius>
JITCompiler: done jitting:<anon class>.Object.each at generated_code_in_test_yield_enum:0
<enebo>
I say let simple fail and then fix it
<headius>
millions of those during test:mri:jit
<headius>
not saying that's a problem...they must be GCing
erikhatcher has joined #jruby
<enebo>
they do generate a lot of tests on the fly
pjammer has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<headius>
that's all failed compiles in my buffer, which includes gem install rails, rails new, and test:mri:jit
marr has quit []
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/vkhO6
<JRubyGithub>
jruby/master bf5cdee Kevin Menard: [Truffle] Tagged a failing spec.
JRubyGithub has left #jruby [#jruby]
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 246 seconds]
<headius>
enebo: so what do you think about 2000 then
<headius>
that would reduce this to only 2 or 3 that fail to compile in all my testing
<headius>
as short-term fix anyway
<enebo>
headius: yeah I guess then asking bbrowning_away to retest will help give a little more confidence in a much broader suite
<headius>
yes
<chrisseaton>
Wow Truffle can actually run this lexer
<enebo>
chrisseaton: were you concerned? Or you just mean you were not sure you impld enough of ruby yet?
<chrisseaton>
I didn't expect it to run without any modifications or tweaks at all
<chrisseaton>
We exceed the maximum frame size of 16k when compiling it though
<headius>
unsurprising
<enebo>
congrats on running it vanilla
<chrisseaton>
one of the problems of always being able to deopt, is you have to keep a lot of junk live, just in case someone wants to introspect the frame