yfeldblum has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 240 seconds]
colinsurprenant has joined #jruby
<colinsurprenant>
pitr-ch: u around?
* rtyler
hides
colinsurprenant has quit [Quit: colinsurprenant]
tenderlove has quit [Quit: Leaving...]
colinsurprenant has joined #jruby
<colinsurprenant>
:P
<rtyler>
I worked on embedding a gem in a java library today
<rtyler>
jruby/gradle made that fairly easy
<rtyler>
I need to write a blog post about it
yfeldblum has joined #jruby
havenwood has quit [Read error: Connection reset by peer]
djbkd has quit [Quit: My people need me...]
yfeldblum has quit [Ping timeout: 240 seconds]
colinsurprenant has quit [Quit: colinsurprenant]
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 264 seconds]
bffff_ has joined #jruby
nirvdrum has joined #jruby
r0bby_ has joined #jruby
r0bby_ is now known as robbyoconnor
robbyoconnor has quit [Quit: Konversation terminated!]
nirvdrum has quit [Ping timeout: 240 seconds]
havenwood has joined #jruby
tcrawley-away is now known as tcrawley
tcrawley is now known as tcrawley-away
havenwood has quit [Remote host closed the connection]
havenwood has joined #jruby
rsim has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
vjdhama has joined #jruby
vjdhama has quit [Remote host closed the connection]
colinsurprenant has joined #jruby
DomKM has joined #jruby
samphippen has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
rsim has quit [Quit: Leaving.]
vjdhama has joined #jruby
<headius>
cremes: something is definitely wrong if we're slower than MRI
<headius>
cremes: did you file an issue?
<headius>
cremes: one thing to check would be if you're hitting memory cap...if it's pushing memory limit it could be spending all its time GCing
<headius>
JRuby is at least 2x MRI on that file mberg pointed out with no special flags (I did bump memory up a bit)
skade has joined #jruby
<headius>
2x faster that is...I'm not seeing what you're seeing
<headius>
cremes: yeah I can't seem to reproduce your slower perf, at least on the file mberg suggested
vjdhama has quit [Remote host closed the connection]
<headius>
hmm, I'm not sure if I'm doing something wrong but rbx is the slowest one
<headius>
nearly 3x slower than MRI on this big file
<headius>
improves to 2x after a few iterations
<headius>
cremes: perhaps you were running with --dev set or something, but JRuby is easily the fastest on this simple csv bench with a very large file
robbyoconnor has joined #jruby
<headius>
jruby with --dev is very slow, unsurprisingly, but it's running slowest of all settings... 22s versus MRI's 6.5s versus 3.3s with no --dev
<headius>
as I've said before, if JRuby runs something slower than MRI, it's usually a bug :-P
bruceadams has quit [Ping timeout: 240 seconds]
bf4 has quit [Ping timeout: 240 seconds]
bruceadams has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
dfr has quit [Ping timeout: 240 seconds]
dfr has joined #jruby
rsim has joined #jruby
rsim has quit [Client Quit]
vjdhama has joined #jruby
vjdhama has quit [Remote host closed the connection]
<projectodd-ci>
* eregontp: [Truffle] Produce a java command more smiliar to the bash script.
<projectodd-ci>
* eregontp: [Truffle] Enable system assertions for specs.
<chrisseaton>
headius: snakeyaml, and I just ported your Java extension to the Truffle API - but this it the first of the big external libraries we need to tackle - next are Nokogiri and OpenSSL
<chrisseaton>
headius: how does the dependency on snakeyaml work? it looks like the jar is dynamically added to the class path, but then where does it come from if it's not a normal Maven dependency? It doesn't seem to appear in the stdlib directory
samphippen has joined #jruby
<headius>
chrisseaton: it is installed from maven using mkristian's stuff, ilb/ruby/stdlib/org/yaml/snakeyaml
cremes has quit [Quit: cremes]
<chrisseaton>
headius: why can't it just be a normal maven dependency like joni and things like that?
cremes has joined #jruby
<headius>
those are shaded into the main JRuby jar
<chrisseaton>
right - so why not snakeyaml?
<headius>
we're moving toward treating external maven deps as dependencies so everyone isn't vendoring their own copies
<headius>
at least when they're only deps for a library and not for jruby itself
<headius>
cremes: yeah, something's seriously busted here
<headius>
csv was easily fastest without the converter stuff
<headius>
and I bet I know the problem
<cremes>
headius: yes, without :converters => :all it probably runs a lot quicker.
<cremes>
i knew you’d get to the bottom of it quickly
<headius>
any time you have this kind of perf discrepancy it's a bug
<headius>
we are not slow :-)
<cremes>
i was planning to open an issue…
<cremes>
heh, no you aren't
* cremes
senses a 9.0.2.0 release coming…
<headius>
it has been about a month, so probably good timing
<headius>
we're just not getting that many big issues with 9k
<headius>
yup, here's the problem...it looks like something is using exceptions as flow control
<headius>
huge amount of time spend creating stack traces in JVM profile
<cremes>
headius: don’t be satisfied until its 3x faster than MRI :)
<headius>
no worries
enebo has joined #jruby
<headius>
yup, csv allows the converters to raise exception to trigger next one
<headius>
basically if you need the last one in the list (float), you end up getting three full exceptions to get there
<headius>
this is likely the problem others have had with csv too
<headius>
they're also blocks and I've still been too lazy to get blocks jitting
<headius>
guess I should do that
<chrisseaton>
what's holding you back there? can't you just jit them like any other method?
<headius>
well we optimize code to reduce overhead once jitted, and we can't optimize a block without also optimizing its parent method
<headius>
it's not a huge deal, we just need to walk up to the nearest non-block scope and tell it to compile
<enebo>
chrisseaton: assumptions are made about how to access parent captured variables
<headius>
and then get the bits in the right place
vjdhama_ has joined #jruby
<chrisseaton>
ah right - we had some logic at one point to try to get surrounding methods to compile when a block was compiled - never really sorted it out
vjdhama has quit [Read error: Connection reset by peer]
<chrisseaton>
Definitely a sensible idea - if a loop body that is a block is compiled, we should compile the method as well
<headius>
chrisseaton: yeah exactly
<enebo>
headius: we may have enough flags on IRScope to know how that scope stores vars
<headius>
the fiddly bit is getting all the other blocks in that scope to know they've been compiled too
<enebo>
headius: but we could add jit flags maybe so you can record what you did
<headius>
normally blocks are activated by their parent method, but in the rootless case they live in a RubyProc somewhere
<headius>
we need to know where
<headius>
enebo: perhaps
<headius>
it's just messy to do it without compiling parent scope
<enebo>
headius: just thinking we do not use temps or anything like that in methods if they even contain closures
<headius>
the other messy bit is compiling parent scope in this case would compile the entire csv module, which would compile all methods in it, etc
<enebo>
heh
<headius>
not exactly what we want :-)
<enebo>
yeah blocks in non-methods
<headius>
your work on define_method opto may fit here
<headius>
if we can just treat it like a free-standing method it would be easier
<headius>
IRClosure is not as friendly for standalone JIT
brauliobo has quit [Ping timeout: 264 seconds]
<enebo>
this is almost entirely not know about how to access captures right?
vjdhama has joined #jruby
<enebo>
it is the only thing which comes into my head
<headius>
so with the simplest hack (turning off stack traces in JVM) I'm already nearly MRI speed
vjdhama_ has quit [Ping timeout: 246 seconds]
<enebo>
headius: you looking into cremes csv bench?
brauliobo has joined #jruby
<headius>
yeah
<enebo>
headius: when I popped over here I saw you mention 3x exceptions per row?
<enebo>
err 3
<headius>
csv parsing isn't the problem, it's a combination of a crapload of exceptions being raised and the converters not jitting
<headius>
3-4 exceptions *per value*
<enebo>
hahaha
<headius>
I'm amazed we ever finished
<enebo>
well that explains the slowness
<headius>
yeah
brauliobo has quit [Read error: Connection reset by peer]
<headius>
we should be able to fix this up but it will require improving csv itself
<enebo>
HAHA
brauliobo has joined #jruby
<headius>
"improving" as in making not gross
samphipp_ has joined #jruby
<headius>
enebo: csv.rb:947
<enebo>
rescue f
<enebo>
love it
<headius>
yup :-)
TheWhip has joined #jruby
vjdhama has quit [Ping timeout: 252 seconds]
skade has quit [Quit: Computer has gone to sleep.]
<headius>
yeah, this is pretty gross
<headius>
they re-encode the input every time too
vjdhama has joined #jruby
samphippen has quit [Ping timeout: 250 seconds]
<headius>
Kernel#Integer needs an exception-free form
<enebo>
headius: call me crazy but we can probably get rid of overhead of rescue nil; pattern
<headius>
call me maybe
<enebo>
headius: $! does not live on
<enebo>
is there some other side effect I am missing?
<headius>
it would need to modify the call and set some flag to not generate stack trace
<enebo>
sure
<headius>
the stack trace happens arbitrarily deep in the attached expression
<enebo>
oh
<enebo>
yeah we do not know where it starts
<enebo>
ok heh
<enebo>
much harder but still possible
<enebo>
begin; Thread.new { raise e } ; rescue nil; end
<enebo>
ignore that probably will not trigger but fact that the flag would need to possibly jump threads makes it weirder
<headius>
.join would trigger it
<enebo>
sure
<enebo>
just a snippet
<enebo>
a field on TC as potential small opt
<enebo>
so any catch basically if is this form sets a simpleException field
<enebo>
any others will just set it to false
<enebo>
then only innermost one will work (without save/restore)
<headius>
enebo: yeah that would be a reasonably simple one
<headius>
context.inSimpleRescue()
<enebo>
yeah
<enebo>
it would probably work for majority of cases
<headius>
I'm going to work around the exception thing for now and see what else we're losing on perf
<enebo>
if just means all exceptions at raise need to check a boolean
<headius>
we're just about MRI speed at this point but we should be faster
<enebo>
and possibly restoring saved values as it unwinds past the rescue nil for nested ones
<enebo>
which I think would be overkill
<headius>
oh that's true
<headius>
regular raises with full rescue would still need to capture stack
<headius>
so only exceptions raised below simple rescue can omit
<enebo>
below == deeper
<enebo>
?
<enebo>
only deeper can omit and then has to unset that field once it unwinds past that point
<enebo>
but we can keep omitting if it the field was true at the point we reached that rescue nil
<headius>
I mean nearest rescue must be simple
<headius>
if there's any intervening rescues that might rescue this exception it needs full trace
<headius>
we can't lazily generate trace you know
<headius>
we have to decide at point of exception or the trace is lost forever
<headius>
cremes: well, fwiw, without converters on we're easily fastest again
<headius>
around 20% faster than MRI and 3x rbx
<enebo>
yeah
<enebo>
headius: yeah the field is only for nearest exception
<headius>
right
vjdhama has quit [Ping timeout: 244 seconds]
vjdhama has joined #jruby
<enebo>
headius: I just saw what you said above…define_method and lambda {} can basically leverage the same code I think. I do not think lambda spreads arrays by default so may be pretty much the same conversion
<enebo>
headius: both also need to inject check_arity instr
<headius>
ok, with no stack traces and the converters as methods we're same ratio faster than MRI with converters on
<headius>
yay
<headius>
cremes: we are fastest again on your bench with a couple quick hacky fixes
<enebo>
so if we can relalize non-capturing lambdas as methods then we will be in business without needing to change this code
<headius>
that will be one bottle of scotch, please
<enebo>
if we can also detect rescue nil we might be able to work around that
<enebo>
we can keeping changing source code but we can work around both problems for this particular code and perhaps we should instead of changing the world around our impl
<headius>
cremes: faster than MRI by almost 2x at this point
vjdhama has quit [Read error: Connection reset by peer]
vjdhama has joined #jruby
TheWhip has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1 has quit [Client Quit]
<cremes>
headius: never let it be said that i don’t appreciate you. private msg me your addr and i’ll get you a nice scotch again. ;-)
<cremes>
headius: so 2x faster than mri now… hmmm, is it producing correct output? :P
<headius>
well that's for you to figure out :-)
<headius>
if you want a temporary fix that solves 90% of this, pass -J-XX:MaxJavaStackTraceDepth=0
<cremes>
how does one go about getting these hacks for 2x improvement?
<cremes>
ah, ok, will try that
<headius>
that will obviously nuke stack traces for all exceptions, but you probably don't need them right now
<enebo>
cremes: I believe we can make that code as written this fast too but that won’t be done today :)
<cremes>
he
<cremes>
s/he/heh/
brauliobo has joined #jruby
<headius>
cremes: csv patch in the bug now
<cremes>
headius: using that -J on the cli with the benchmark, jruby is still slower than mri & rbx on my system
<cremes>
not by much, but about 10%
<enebo>
headius: ah one issue with converting lambdas in general may be case where they are converted to lambdas
<headius>
with that JRuby improves to 11s cold, 9s hot, where MRI and Rubinius are in the 14-15 range
<headius>
yeah try the patch
<enebo>
heh I mean bindings
<headius>
the converters all run interpreted without the patch
<headius>
that got me from 17s to 9s
<cremes>
ok, trying now
<headius>
enebo: btw, yorick's oga perf issue the other day was another closures-not-jitting thing
TheWhip has joined #jruby
<headius>
he generates his "compiled" xpath as rootless procs
<headius>
or at least, I'm pretty sure that's the main problem
<enebo>
so we can convert lambda to method but must be able to reconstitute a binding which I guess is not hard for non-capturing lambdas
<headius>
yeah at least in csv these are non-capturing
<headius>
you can see the patch in cremes bug...I just made them into Method objs
<enebo>
yeah I am thinking the first pass for both define_method and this is non-capturing case
<cremes>
headius: working on applying the patch now… i’ll report back in a ew
<enebo>
headius: although perhaps we can also reexamine method(:foo) and get rid of some overhead
<headius>
enebo: it should be pretty tight
<headius>
it does specific arity and all
<headius>
but it doesn't bind properly through indy, so losing that
<headius>
that's a five minute fix though
<enebo>
ok
<headius>
well maybe more than five...it needs to specialize Method#call to dig out the actual method and check if the target Method object ever changes
<enebo>
headius: can it?
<headius>
sure
<enebo>
headius: if you redefine foo does method(:foo) follow the new def?
<headius>
no
<headius>
it grabs it once
<enebo>
ok so it cannot change then
<headius>
so it just needs to know it's same Method object and same :call
<headius>
the reset is bound
<cremes>
headius: jruby is once again king of that hill!
<headius>
cremes: yay
<headius>
this is a great find in any case, thanks for bringing it up
<headius>
I'll work with jeg to improve csv
<cremes>
my pleasure. we all work together to make things better.
vjdhama has quit [Ping timeout: 260 seconds]
vjdhama has joined #jruby
donV has quit [Quit: donV]
<headius>
cremes: indeed! community begets community!
cprice has quit [Quit: Konversation terminated!]
brauliobo has quit [Ping timeout: 260 seconds]
brauliobo_ has joined #jruby
TheWhip has quit [Remote host closed the connection]
<nirvdrum>
headius: to_i is the exception free form, no?
<headius>
yes, but it returns 0 for bad input rather than some non-numeric signifier
<GitHub43>
[jruby] mkristian commented on commit b40bc95: looks ok to me
rsim has quit [Quit: Leaving.]
yfeldblum has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
<chrisseaton>
does anyone know why JRuby is so messed up on Travis right now? master branch
<chrisseaton>
ah no sorry - it's just my branch... weird
pitr-ch has joined #jruby
thsig has joined #jruby
djbkd has joined #jruby
rsim has joined #jruby
thsig has quit [Ping timeout: 240 seconds]
yfeldblum has quit [Ping timeout: 240 seconds]
yfeldblum has joined #jruby
shellac has quit [Ping timeout: 264 seconds]
colinsurprenant has quit [Quit: colinsurprenant]
donV has joined #jruby
brauliobo_ has joined #jruby
bbrowning is now known as bbrowning_away
brauliobo has joined #jruby
brauliobo_ has quit [Ping timeout: 265 seconds]
vjdhama_ has joined #jruby
vjdhama has quit [Ping timeout: 250 seconds]
pivotal has joined #jruby
pivotal is now known as aberlin
<aberlin>
I'm looking for help debugging an issue w/ Jruby
<aberlin>
when I try to require a file, I get this error: java.lang.NoClassDefFoundError: sun/io/ByteToCharConverter:
<aberlin>
specifically, trying to load a Ruby file.
yfeldblum has quit [Ping timeout: 246 seconds]
bf4 has joined #jruby
donV has quit [Quit: donV]
vjdhama_ has quit [Read error: Connection reset by peer]
vjdhama has joined #jruby
<nirvdrum>
aberlin: Odd. What version of JRuby and which JVM?
aberlin_ has joined #jruby
aberlin has quit [Read error: Connection reset by peer]
brightball has quit [Quit: Leaving...]
havenwood has joined #jruby
thsig has joined #jruby
thedarkone2 has joined #jruby
thsig has quit [Ping timeout: 240 seconds]
<GitHub127>
[jruby] DougEverly opened issue #3351: SecureRandom is slow or hangs. http://git.io/vnN89
vjdhama has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
vjdhama has joined #jruby
yfeldblum has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
<aberlin_>
@nirvdrum 9.0.0.0
<aberlin_>
± at+cs |master ✗| → jruby -v
<aberlin_>
jruby 9.0.0.0 (2.2.2) 2015-07-21 e10ec96 Java HotSpot(TM) 64-Bit Server VM 25.45-b02 on 1.8.0_45-b14 +jit [darwin-x86_64]
bbrowning_away is now known as bbrowning
phrinx has joined #jruby
<aberlin_>
@nirvdrum thanks for the tip. I switched from 1.8 to 1.7 and it started working again.
<headius>
cremes: hey I'm curious why you mentioned "don't stop until you're 3x MRI"...that number seems arbitrary
<headius>
we're around 2x with fixes and could go farther, but I'm wondering what your actual app's perf looks like now
<cremes>
headius: just got back… yeah, 3x is arbitrary. i’d like ludicrous speed, please.
<rtyler>
according to mkristian there's some JRubyUrlClassloader stuff from 1.7.16 onward which will create /tmp/jrubyXXX.jar files at runtime
<headius>
ok :-)
<cremes>
as for the app, this is a set of scripts to parse hundreds of CSV files and load them into a database
<rtyler>
do any of you fine folks know if there's code that will clean those up or anything?
<cremes>
as of now, it’s about the same speed as running under rbx. the upside is that rbx was periodically segfaulting so i needed a watchdog to kill it.
<cremes>
no such requirement with jruby; solid as a rock.
<headius>
cremes: ahh ok, I was wondering what you were actually running
<cremes>
the main process takes a largish (400k+ lines) CSV file and chops it into equal bits. then it launches N threads. each thread gets an IO handle to one of the equal bits. then it parses it and passes batches that are ready for bulk insert to a dedicated thread that just does DB inserts.
<cremes>
scales nicely with rbx & jruby. does *not* scale at all with mri since it does I/O.
<headius>
you running on 1.7 or 9k?
<cremes>
9.0.1.0
<headius>
cool
<cremes>
with your csv patch and suppressed stack frames
<cremes>
or whatever :)
<headius>
yeah, apparently there's a better JVM flag for that, -XX:-StackTraceInThrowable
<headius>
dunno if it will be faster, but every little bit...
<cremes>
i’ll try it out
<headius>
cool...landing some of the fixes now for 9.0.2
djbkd has quit [Remote host closed the connection]
<cremes>
headius: about 4-7% improvement with that additional jvm flag
vjdhama has quit [Read error: Connection reset by peer]
* chi6rag
slaps vjdhama around a bit with a large fishbot
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
samphippen has joined #jruby
vjdhama has quit [Ping timeout: 256 seconds]
vjdhama has joined #jruby
<rtyler>
headius: back, are there any other tickets that might be related to updating the classloader?
<rtyler>
wondering if it's within my capabilities
donV has joined #jruby
donV has quit [Client Quit]
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jensnockert has joined #jruby
yfeldblum has joined #jruby
bbrowning is now known as bbrowning_away
yfeldblum has quit [Read error: Connection reset by peer]
pitr-ch has quit [Ping timeout: 244 seconds]
yfeldblum has joined #jruby
vjdhama has quit [Read error: Connection reset by peer]
vjdhama has joined #jruby
<rtyler>
gak, now I have to remember how I set up intellij to call the right maven for jruby >_<
donV has joined #jruby
Puffball has joined #jruby
<headius>
lopex: enebo is working to be carb-neutral
<headius>
chi6rag: I have not looked at that in a while
<headius>
the basic issue is that on case-preserving systems, you can glob for the lowercase name and it finds the file, but MRI returns actual case and we don't
<headius>
I'm not sure what they do above and beyond what we do
<rtyler>
headius: based on my read of this code, there's no need for this JRubyClassLoader to inherit from URLClassLoader so long as it implements the ClassDefiningClassLoader API properly
<rtyler>
does that sound stupid?
<rtyler>
but there's no unit tests of JRubyClassLoader directly so I'm not sure how to proprly not screw this up
<headius>
rtyler: depends if it's using any features of URLClassLoader
<headius>
or if we cast it to URLClassLoader for other purposes
<rtyler>
eeep
<rtyler>
it's used in Ruby
<rtyler>
46 usages off Ruby.getJRubyClassLoader() alone
* rtyler
dies
<lopex>
headius: like neutral == none ?
<lopex>
or average ?
<headius>
I suppose that depends how much carbs a person actually needs :-)
<headius>
rtyler: well it's used but if it exposes the right functionality it doesn't necessarily have to extend URLClassLoader
mbj has joined #jruby
<headius>
URLCL was used originally because it provides dynamic jar loading without a lot of hassle
<rtyler>
headius: right, how confident are you in the tests around this? since unit tests are non-existent
<rtyler>
I just don't wanna be the dude that breaks a lot of shit
<rtyler>
:P
<headius>
there's a lot of tests for systems that use the CL
<headius>
and mkristian knows a lot about how it is being used too
<rtyler>
yeah, he's sleeping in an airport right now
<rtyler>
so not a lot of help :P
<lopex>
headius: I have no limits
<headius>
rtyler: hah
<rtyler>
(flight was cancelled)
<headius>
well, doesn't hurt to try making changes and see if anything breaks :-)
<rtyler>
I basically started this issue with him this morning but he ran out of laptop juice
<rtyler>
man I wish this thinkpad weren't so weak
<rtyler>
running mvn verify is crushing me
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rtyler>
eeeep and it fails at HEAD of master for me
<rtyler>
daggumit
<rtyler>
headius: would you consider the JRubyClassLoader to be a stable public API, or is it acceptable to change it and the usages of it slightly?
<rtyler>
URL url = file.toURI().toURL();
<rtyler>
heh, had to double-take there
<rtyler>
thought that was a redundant call to toURL
mbj has quit [Ping timeout: 256 seconds]
<rtyler>
I can also tell which code mkristian touched, he's the only person I know that writes java.like( this );
<enebo>
geezus finally got PoC opt running
<enebo>
10 moo rescue nils end up going from 14k to 486k with -X-C
<enebo>
using ips
<enebo>
It appears to be executing all the thingies
xardion_ has joined #jruby
<enebo>
JVM numbers as soon as I remember how to set a field in ASM
thsig has joined #jruby
<kwando_>
just wanna say that you guys do an awesome job with jruby! =D
xardion_ has quit [Quit: ZNC 1.7.x-git-441-d66cb36 - http://znc.in]
vjdhama has quit [Read error: Connection reset by peer]
thsig has quit [Ping timeout: 264 seconds]
<enebo>
kwando_: thanks we love what we do :)
* rtyler
tries to parse maven output
xardion has quit [Quit: leaving]
<rtyler>
[INFO] [java] LoadError: library `java' could not be loaded: java.lang.NoSuchFieldError: closure
<rtyler>
that doesn't seem right .
<lopex>
mismatched versions ?
<rtyler>
i just grabbed HEAD of master and ran the verify goal
<rtyler>
success outside of intellij, bollocks
<lopex>
internal stacktrace would give more info
mbj has joined #jruby
<rtyler>
meh forget it, I'll just stick to vim
<rtyler>
this is already turning into an annoying waste of time :P
<rtyler>
I have a very low threshold for pain with big maven projects
<headius>
kwando_: thank you!
<lopex>
rtyler: and the time grows expotentially
<lopex>
but mutable cycle phases is the main concern I hear
brauliobo_ has joined #jruby
mbj has quit [Ping timeout: 240 seconds]
<rtyler>
lopex: huh?
<lopex>
rtyler: maven is slow
<rtyler>
oh yeah
<rtyler>
I'm obviously very fond of gradle :P
<lopex>
and prone to plugins bugs
<rtyler>
wat, where the hell do compiler errors go o_O
<nirvdrum>
lopex: Have you ever considered just statically defining the results of RubyEncoding#areCompatible?
<nirvdrum>
While someone could in theory write their own encoding and the method would have to account for that, in reality it's a small number that hasn't changed in years.
<lopex>
nirvdrum: results ?
<nirvdrum>
The method negotiates one of the encodings and returns it.
<nirvdrum>
It's not a simple predicate.
<lopex>
nirvdrum: oh, I guess I had a similar impression when porting it
<headius>
does gradle use any of maven?
<headius>
I mean, maven is many things
<headius>
mven as a build lifecycle is definitely cumbersome but as a dependency manager it works pretty well
<lopex>
wow, that method is awful
<rtyler>
I think the problem was that I had compiled some bad code before, and then I didn't properly resume the failed build, so everything after just failed?
* rtyler
seethes
<rtyler>
headius: ShrinkWrapClassLoader inherits from URLClassLoader, this might actually be super easy
<rtyler>
since we're already overwriting addUrl for custom nested jar behavior
<nirvdrum>
lopex: It seems like the sort of thing we could have a rake task for and just dump out Java code to populate a map.
yfeldblum has quit [Ping timeout: 240 seconds]
<headius>
rtyler: sounds good to me
<headius>
SWCL seems to do everything we need
<rtyler>
headius: assuming my testing goes well I should be able to get something to you soon
<rtyler>
now that I've bludgeoned maven into submission, for now
<headius>
excellent!
<headius>
enebo: optimize gvar sets or not?
<headius>
gvar gets are now as fast as ivar gets
<headius>
caching et
<headius>
etc
<rtyler>
headius: is `verify` the right goal to execute all tests?
<enebo>
heh
xardion has joined #jruby
<enebo>
headius: I didn’t care about gvar gets :)
<headius>
enebo: luddite
<enebo>
headius: but if it does not complicate the codebase I don’t have an opinion :)
<rtyler>
it looks like provided in our addURL() if we can create a proper Archive instance it should be doable to get that into the classloader
<rtyler>
but the fact that that is freakin' private is annoying
<rtyler>
I don't think there's anyway to break that visibility is there? copypasta ahead?
<headius>
hmph...I'm confused why global writes are so much slower
<lopex>
dark matter
<headius>
rtyler: so the issue is that they want all Archive at construction time?
<rtyler>
yeah
<headius>
maybe we should talk to them about that
<rtyler>
yeah, I'm planning on opening an issue
<headius>
that's a strange limitation given how much other stuff this does
<rtyler>
well, so it looks like this is the only novel thing this class does
<headius>
copypasta would suck but I guess it would work
<rtyler>
which means, no need to incorporate ShrinkWrapClassLoader specifically into our inheritance hierarchy
<rtyler>
"To file issues or requests with JIRA, you must have a JBoss Community account (don’t worry, registering is easy)."
<rtyler>
i'll pass
* rtyler
sighs
<headius>
bleh
<headius>
exactly why we moved to github
<headius>
nobody wants to make more accounts
<rtyler>
their IRC is pretty dead too
<rtyler>
which is also a bummer
<headius>
ping aslak on twitter
<headius>
he was the first to suggest it to us
jensnockert has quit [Remote host closed the connection]
<rtyler>
yeah, he provided a patch for using shrinkwrap in jem
<headius>
go to the horse
<rtyler>
although there's stupid classloader issues with the way it imports extensions
<rtyler>
so I can't incorporate it into the gradle plugins yet
jensnockert has joined #jruby
<rtyler>
which also likely means this is going to explode in an OSGi context
<rtyler>
which will make mkristian sad
<headius>
haha yeah probably :-)
<headius>
bleh, whatevs...I guess I don't care about global assignment being slower than other assignment either
<headius>
it's still like 5x MRI anyway
<rtyler>
\o/
brauliobo_ has quit [Ping timeout: 255 seconds]
<headius>
oh bleh, it's not
<headius>
but why?!
cristianrasch has quit [Quit: Leaving]
<rtyler>
aliens
drbobbeaty has joined #jruby
<rtyler>
hrm, it seems that even if you make a failing JUnit test, maven goes into this resumable build nonsense
djbkd has quit [Remote host closed the connection]
rcvalle has quit [Quit: rcvalle]
<nirvdrum>
lopex: Is there any way to get an EncodingEntry index from an Encoding?
<lopex>
nirvdrum: getIndex ?
<lopex>
ah
<lopex>
wait
djbkd has joined #jruby
<lopex>
nirvdrum: you mean Entry ?
<nirvdrum>
Yes. Sorry.
<headius>
I love when turning on profiling it speeds up a benchmark
<headius>
grr
<rtyler>
omg this is impossible to TDD
<lopex>
nirvdrum: afaik the index from entries gets propagated to encoding instances
<lopex>
nirvdrum: if not, then there should be a mapping table ( afaik ther's a bug for that)
<lopex>
nirvdrum: all integer mappings
<nirvdrum>
There's a mapping table in EncodingService. But that gets populated when you load the encoding.
<nirvdrum>
I'm trying to get the value before then.
<nirvdrum>
Oh well. Thanks anyway.
<lopex>
nirvdrum: I know it's convoluted, it's all remnant
<lopex>
nirvdrum: well, some of that isthe lazy loading for encodings
<nirvdrum>
I took a shortcut and eagerly loaded all of them when I did this way back when for Truffle. I'm trying to undo that mistake.
<lopex>
nirvdrum: the biggest mistake is on my part though, I always tried to lazy lod the classes
<lopex>
nirvdrum: and that didnt play well with those indexes
<nirvdrum>
lopex: And really it's just the handling of these special encodings that's problematic.
<lopex>
nirvdrum: yeah
<headius>
time to make dinner here, bbl all
<rtyler>
FWIW it looks like the only way to get a proper TDD flow with maven is to use the --fail-at-end flag, otherwise the reactor plugin will always kick you into a resumable build state