_whitelogger has joined #jruby
shellac has joined #jruby
drbobbeaty has quit [Ping timeout: 265 seconds]
claudiuinberlin has joined #jruby
drbobbeaty has joined #jruby
rdubya has joined #jruby
bbrowning_away is now known as bbrowning
rdubya has quit [Ping timeout: 255 seconds]
mistergibson has joined #jruby
rdubya has joined #jruby
claudiuinberlin has quit [Ping timeout: 256 seconds]
<enebo> kares: you see my question from friday about 52.0
<enebo> kares: I also wonder if perhaps our .jar commit change broke gem install a little bit: https://github.com/jruby/activerecord-jdbc-adapter/issues/924
<enebo> I will look into that this morning
<enebo> oh ignore that issue I guess. this is just the limitation that we need ant installed to use ant support
<lopex> enebo: can you release jcodings, I forgot all caseMap impls are there now
<lopex> enebo: also I found a usage for matcher.match for String#start_with?
<enebo> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on project jcodings: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.: NullPointerException -> [Help 1]
<enebo> lopex: ^ NPE running default-test
<enebo> oh hmmm I used Java 10
<enebo> although I would hope tests would still run
<lopex> enebo: you have stacktrace ?
<enebo> no
<enebo> but Java 8 is working
<enebo> so something with Java 10 breaks this
<lopex> enebo: maybe some outdated maven plugins ?
<enebo> lopex: joni should also now be released with this newer version?
<enebo> lopex: yeay maybe?
<lopex> no
<enebo> ok
<lopex> I'll try mvn versions:display-dependency-updates
<lopex> junit only
<enebo> joni does have jcodings as a dep thoguh
<lopex> there's isnt any magic in jcodings, not even reflection now
<enebo> lopex: yeah it may be test plugin or something perhaps
<enebo> lopex: but why would we not update joni to use newer jcodings? Not ready yet?
<lopex> enebo: there's additional args for javadoc
<lopex> linting is turned off
<lopex> enebo: ah, you mean joni dep, yeah
<enebo> ok
<lopex> enebo: so, wrt that interruptible, we should obey that for all matcher calls right ?
<enebo> lopex: yeah
<enebo> lopex: amazingly I only found two paths
<lopex> enebo: there's only '\X' as a pattern so no way it can stuck in the interpreter
<enebo> lopex: shoot...I remember these too
<enebo> basically 2 calls in grapheme metdhos
<enebo> lopex: I found these and then forgot about them
<lopex> yeah, it looks for a grapheme at that position
<enebo> lopex: so I think only 4 paths in
<lopex> so no need to search
<enebo> lopex: but I definitely missed these
<lopex> enebo: also I wonder if a regexp has a ^ we could potentially use match directly ?
<enebo> lopex: yeah seems reasonable to me
<lopex> oh, well it's being taken care of in search too
<enebo> lopex: yeah if it can be encapsulated that would be better since we would need to leak that out
<enebo> leak info that is is ^ or \A
<lopex> enebo: but we can count quantifiers at least and expose that
<enebo> although I guess those mildly differ for multilines
<enebo> match? we did not quite catch MRI
<enebo> for tiny strings anyways
<lopex> maybe we should profile that
<enebo> My theory is that we construct a bunch of objects per match that MRI does not since MRI does not allow parallel execution of regexps
<lopex> like ?
<enebo> well we set up joni engine
<enebo> I have not done object profiling so perhaps I am wrong there
<lopex> yeah, the matcher, but that's about it
<enebo> well that might be enough
<enebo> match? on a string like "9:30" is not going to take a lot of work
<enebo> so object allocation may be pretty visible in tiny string matches
<enebo> It's just a theory though
<enebo> lopex: oh and I release jcodings about 10 minutes ago...not sure when it will show up though
<lopex> ok
xardion has quit [Remote host closed the connection]
shellac has quit [Ping timeout: 240 seconds]
xardion has joined #jruby
Eiam has joined #jruby
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
<lopex> enebo: isnt there a bug in second execute ?
<lopex> enebo: well, we don want to read that volatile if interrupt is true ?
<enebo> lopex: oh yeah it should be interupt && interrupted
<enebo> right?
<lopex> enebo: I'm asking you :P
<lopex> er, false I meant
<enebo> oh I think this is ok
<lopex> well, they also differ
<enebo> the first if means if someone explicitly interrupted from outside interupted is true so we still look to see if we should exit
<enebo> second if is performing an external check via isInterrupted
<lopex> they should be the same
<enebo> lopex: first if supports interrupting work from outside thread interrupt checking
rdubya has quit [Ping timeout: 260 seconds]
<enebo> lopex: so an external thread can call bytecodemachine.interupt() and it will set that boolean
<enebo> lopex: so even with interupt == false we still check that boolean
<lopex> enebo: so the second is wrong
<enebo> lopex: I don't see why?
<lopex> enebo: so the first ?
<enebo> interrupt passed into executeSb is specifically only for check currentThread.isInterrupted
rdubya has joined #jruby
<enebo> those two if exprs ORd are two different things
<lopex> enebo: why execute and executeSb have different impls ?
<enebo> personally I don't know why it is not just interrupted || interrupt && check
<enebo> lopex: I think one in execute() is better than executeSb because if explicitly set interupted it should not matter
<enebo> lopex: so I agree executeSb should just be like execute
<lopex> ok
<enebo> lopex: can you change that? I am trying to release some arjdbc gems
<enebo> ultimately that change is not all that important since I don't think we have any users yet explicitly interrupting from outside joni
<enebo> but we should still make the change for consistency
<lopex> enebo: also added begin line / end line singlebyte specializations
<enebo> lopex: so for 7bit we can match on search?
<lopex> enebo: it's just in executeSb change
<enebo> yeah but Sb is only for 7bit right?
<enebo> lopex: so any recent changes which get better performance?
<lopex> enebo: from today
<enebo> lopex: or recently
<enebo> lopex: I know you made some changes you had to revert in jruby itself
<enebo> lopex: that was to reduce setting $~?
<lopex> it was in match data
<lopex> no, it was to make pattern access cheaper
<enebo> ah ok
<lopex> enebo: I'll make more changes after release ?
<enebo> lopex: sure thing
<lopex> er, disregard that question mark
rdubya has quit [Ping timeout: 265 seconds]
atm1sk has quit [Quit: leaving]
flavorjones_ has joined #jruby
flavorjones has quit [*.net *.split]
snowp has quit [*.net *.split]
flavorjones_ is now known as flavorjones
drbobbeaty has quit [Ping timeout: 256 seconds]
Puffball has quit [Remote host closed the connection]
Puffball has joined #jruby
rdubya has joined #jruby
Eiam_ has joined #jruby
Puffball has quit [Remote host closed the connection]
Eiam has quit [Ping timeout: 276 seconds]
Puffball has joined #jruby
rdubya has quit [Ping timeout: 255 seconds]
mistergibson has quit [Quit: Leaving]