<GitHub137>
[jruby] chrisseaton pushed 1 new commit to truffle-new-instrumentation: https://git.io/vz4Ag
<GitHub137>
jruby/truffle-new-instrumentation 2786a43 Chris Seaton: [Truffle] Add RubyStatement wrapper node.
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<headius>
kares-: ok
<headius>
chrisseaton: whitequark commented, but I don't think there's a lot of string alloc in parser
<headius>
there is, however, a GIANT Lexer.advance method that compiles to 19k instructions in IR and is over 5000 lines long
<headius>
normal JRuby can't do a lot with that
<headius>
partial eval might be able to do better, but running their benchmark on JRuby+Truffle is a few times worse than JRuby 9k
e_dub has quit [Quit: Leaving]
e_dub has joined #jruby
<headius>
kares-: the opcode failure is strange
<headius>
master probably uses a newer ASM though
<kares->
but it did not fail before the merge
<headius>
true is not an opcode
<headius>
I don't think
<headius>
can you push your merge to a branch please?
<headius>
lopex: I am now
<kares->
headius: already pushed to master as locally all seemed well :(
<headius>
just push origin master:bad-master
<headius>
or something
<lopex>
headius: I've done some reading, I was wrong about those code point sizes
<lopex>
headius: it appears none of the encodings we support should exceed 31bits
dlbirch has joined #jruby
<headius>
lopex: well, no harm done anyway
<lopex>
headius: I vaguely remember tbray mentioning such exist
<kares->
headius: pushed test-merge-1_7
<GitHub121>
[jruby] kares created test-merge-1_7 at b35397b (+0 new commits): https://git.io/vz4jg
<kares->
here it is :)
<lopex>
headius: and unicode history is even more interesting
ITXpander has joined #jruby
dlbirch has quit [Client Quit]
<headius>
kares-: so is it just the one failure, or two?
<kares->
headius: just one - the new specs are passing an old one is failing
<kares->
there's 2 failures in ji specs but those are mostly typos fixed on master
donV has joined #jruby
bbrowning_ has joined #jruby
pawnbox_ has joined #jruby
guest555 has joined #jruby
atamb0 has joined #jruby
guest555 has left #jruby [#jruby]
mjc_ has joined #jruby
<headius>
ok
slash_ni1k has joined #jruby
rsim has joined #jruby
pjenvey_ has joined #jruby
lanceball has joined #jruby
samuelkadolph_ has joined #jruby
yopp- has joined #jruby
mjc has quit [*.net *.split]
samuelkadolph has quit [*.net *.split]
lance|afk has quit [*.net *.split]
pjenvey has quit [*.net *.split]
pawnbox has quit [*.net *.split]
donValentin has quit [*.net *.split]
atambo has quit [*.net *.split]
bbrowning has quit [*.net *.split]
Cyrus has quit [*.net *.split]
clayton has quit [*.net *.split]
yopp has quit [*.net *.split]
rattboi has quit [*.net *.split]
slash_nick has quit [*.net *.split]
samuelkadolph_ is now known as samuelkadolph
clayton has joined #jruby
<chrisseaton>
headius: yeah I've seen a huge generated method before - I think it was this very gem
<headius>
not really surprising considering we're lexing Ruby here
<chrisseaton>
headius: we should experiment with jitting individual branches or other fragments of methods
<headius>
yeah, we want to do that in IR...JRuby 1.7's compiler would chain mostly-flat method bodies together, and can actually compile this monster
<headius>
chunk and chain
chrisseaton has quit []
<headius>
with some work I could probably get individual basic blocks to JIT into separate JVM bodies but flow control is a challenge
bbrowning_ is now known as bbrowning
<headius>
bodies without early exits would be doable
<headius>
oops, left
chrisseaton has joined #jruby
rsim has quit [Quit: Leaving.]
rattboi has joined #jruby
Cyrus has joined #jruby
Cyrus is now known as Guest68889
<headius>
chrisseaton: how's truffle at handling very large method bodies?
<headius>
I know you can do things like compile loop bodies independently, but this is mostly one big, straight-line body
<chrisseaton>
the partial evaluation is fine as that's linear
<chrisseaton>
but I'm not sure the later graal phases would appreciate it
<headius>
yeah
<chrisseaton>
i think we need to consider that some optimisations in code like this don't need to apply across all the code
<chrisseaton>
so if you have a big top-level switch then maybe you only need to EA within each case statement
<chrisseaton>
headius: did you see we're switching to GitHub as the primary repos for almost all our stuff?
<chrisseaton>
Truffle's primary repo is GH now, and tested on Travis
<headius>
chrisseaton: very nice
haylon has joined #jruby
<haylon>
Hey everyone, I'm back with the same question.
<haylon>
I have a JRuby JAR that I packaged up with Warbler that simply prints Hello World to the screen using Sinatra. However, I get an Error 500 when trying to access it. I dropped the jruby-complete jar into the $CATALINA_HOME/lib folder, but still get this error that I'll post to Gist.
tomjoro has quit [Remote host closed the connection]
<headius>
I'm probably not going to spin wheels on this for 9.0.5 but it doesn't seem like we've checked numbers since 9.0 release
<chrisseaton>
headius: I just changed the warmup parameters
<headius>
ok
<chrisseaton>
If you mean the Rubykon thing, I think I was just better off with a loop of timing loops
<chrisseaton>
headius: anything else was likely to trigger deopt as soon as you started to measure
<haylon>
I also updated my Gist with the output from Tomcat in the console, hopefullythat helps some too.
<headius>
this is primality test
<headius>
not rubykon
<chrisseaton>
yeah but the big discussion about the problems with benchmark-ips was in the Rubykon thread
<chrisseaton>
which is where I did change things
<headius>
well, I'm looking at JRuby proper, which doesn't have the deopt impact
<headius>
or at least not as pronounced
<haylon>
kares: I'm guessing my WAR is trying to load from bin/ but I don't have an executable in there. I then added an exe/jruby_hello_world stub, and tried that out, but it still threw the Error 500, and io/console not supported; tty will not be manipulated
<kares->
Server handler (trinidad,puma,reel,HTTP,webrick) not found. from C:/apache/tomcat-8.0.21/webapps/jruby_hello_world/WEB-INF/gems/gems/sinatra-1.4.6/lib/sinatra/base.rb:1781:in `detect_rack_handler'
<kares->
seems like there's a compatibility issue with rack 1.6 after all :(
<haylon>
Would I specify the rack version in the gemspec, or is that tied to the Sinatra version?
<kares->
haylon: you tell me :)
<kares->
it might be a combination of sinatra+rack 1.6
<kares->
try to get rack down to ~> 1.5
fatephd has joined #jruby
<kares->
can not tell without looking in detail but sinatra was sure not doing detect_rack_handler previously
<kares->
(which was a long time ago when I last tried)
slash_ni1k has joined #jruby
slash_ni1k has quit [Changing host]
slash_ni1k is now known as slash_nick
tcrawley is now known as tcrawley-away
pawnbox_ has quit [Read error: No route to host]
camlow325 has joined #jruby
pawnbox has joined #jruby
thedarkone2 has joined #jruby
fatephd has quit [Read error: Connection reset by peer]
haylon_ has joined #jruby
Osho has quit [Ping timeout: 260 seconds]
Osho has joined #jruby
projectodd-ci has joined #jruby
haylon has quit [Ping timeout: 272 seconds]
<kares->
headius: should I cherry-pick your spec 1_7 commit to master than - all seems well
<kares->
?
<headius>
kares-: yeah sure, I wasn't sure if you had anything else to tweak in the merge
<GitHub105>
[jruby] headius closed issue #3609: Incompatible method lookup under Kernel.load(file,true), aka wrap, on 9.x https://git.io/vzRWf
<GitHub118>
jruby/master 7be804e Charles Oliver Nutter: Base wrapper self on actual top self. Fixes #3609.
skade has quit [Quit: Computer has gone to sleep.]
helio-frota has joined #jruby
<helio-frota>
hi folks
<helio-frota>
FYI
<helio-frota>
past month i wrote:
<helio-frota>
2015-12-01 11:37 <helio-frota> any clue why this error is throw ?
<helio-frota>
2015-12-01 11:37 <helio-frota> i don't know this project 'jnr-x86asm' (yet)
<helio-frota>
2015-12-01 11:35 <helio-frota> using jruby 9.0.4.0 - Could not index class jnr/x86asm/SEGMENT.class at /wildfly-swarm-jruby.war/WEB-INF/lib/jnr-x86asm-1.0.2.jar: java.lang.NullPointerException
<helio-frota>
btw the bug was on Jandex project and was fixed by the author
<helio-frota>
this means this error will not appear anymore when using jruby + wildfly / wildfly-swarm
<helio-frota>
cheers
helio-frota has left #jruby ["Leaving"]
Puffball has quit [Remote host closed the connection]
Puffball has joined #jruby
gaustin has joined #jruby
GitHub165 has joined #jruby
<GitHub165>
jcodings/master fde8846 Marcin Mielzynski: remove dead code
<GitHub165>
[jcodings] lopex pushed 1 new commit to master: https://git.io/vzREi
GitHub165 has left #jruby [#jruby]
hoodow_ is now known as hoodow
subbu|lunch is now known as subbu
<nirvdrum>
enebo: Are the ByteLists provided to StrNode guaranteed to be not shared? I'm making defensive copies at the moment, but I'm wondering if that's unnecessary.
<enebo>
nirvdrum: currently I don’t think they are
<enebo>
nirvdrum: we can make it a guarantee
<enebo>
nirvdrum: I guess
<nirvdrum>
I don't care much one way or the other. I just need to know the semantics. I figured the lexer just built a new one for each StrNode as it goes.
<enebo>
nirvdrum: but with frozen string literals in 2.3 I guess at some point (which will be IR for us now) they will end up as same string by then
skade has joined #jruby
<enebo>
nirvdrum: the next logical opt would be to share at parse
<enebo>
nirvdrum: or perhaps if 3.0 adopts all literals as frozen then the parser would be better served as using the same bytes
<nirvdrum>
enebo: Put another way, is there any way for a ByteList passed to an StrNode to be modified elsewhere during parse?
skade has quit [Client Quit]
<enebo>
nirvdrum: I don’t think so. For some things like D*Node we may construct but that is execution time
<nirvdrum>
Okay. Thanks.
<nirvdrum>
If they're always new, I can assume begin == 0 and end == bytes.length, too.
<enebo>
nirvdrum: so I only bring up 2.3 feature because semantically all literals of the same bytes could be allowed to be same bytes if 3.0 adopts all literals frozen by default
skade has joined #jruby
<enebo>
nirvdrum: I don’t think you should assume begin 0
<nirvdrum>
Alright.
<enebo>
nirvdrum: I think we may even be sharing identifiers off of source line bytes
<nirvdrum>
Then maybe I'm left with copying then.
<enebo>
nirvdrum: I don’t remember
<lopex>
nirvdrum: single bytelist can be shared by a RubyString too
<nirvdrum>
I'd like to be able to use Arrays.hashCode and Arrays.equals.
<lopex>
er, two of them
<nirvdrum>
lopex: Right. I'm asking at StrNode time, where just a ByteList is passed. It's before RubyString construction.
<lopex>
yeah
<lopex>
just two cents :P
<enebo>
nirvdrum: well for now you can get further and then try changing the contract and see how much the lack of copying helps (although it will force eager copying in lexer then)
<nirvdrum>
I'd like to use the backing byte[] directly if I can. But it looks like it makes things a bit harder.
<nirvdrum>
enebo: Really, I just wish I could get a new head pointer to a byte[].
<haylon_>
keres, thank you for your help, and opening that issue with rack. Ineed to hop off here and will be back on tomorrow.
<haylon_>
kares *
haylon_ has quit [Quit: Leaving]
<enebo>
nirvdrum: fwiw it should be really easy to do
<enebo>
StringTerm, HeredocTerm, and identifier are only three string makers I think
<enebo>
nirvdrum: so experiementation might be easier down the line
camlow32_ has quit [Remote host closed the connection]