02:09 <headius> yo

05:58 <headius> lopex, enebo, nirvdrum: I think I've settled bits and pieces for starting to modularize JRuby and dependent libraries. I need to start at the bottom, though, and one of those is bytelist, marked as 2.0 because of "breaking API changes". I need to know if we have more we want to put in 2.0 or if we can just go with it.

05:58 <headius> I can count the number of projects depending on bytelist with one hand so I'm probably worried for nothing, but if we're going to do a big rev it would be nice to clean up things we've meant to clean up

05:59 <headius> On the other hand I don't want to be forced to delay modularization until we can do some unknown amount of work to fill out 2.0

06:02 <headius> I guess a separate question is whether a major rev is necessary just to add module-info (the rest of the jar contents will still be compiled for 1.7 or 1.8 or whatever)

06:04 <headius> wow we bumped bytelist to 2.0 in 2015

06:05 <headius> about a dozen substantive commits since then, not counting my fiddling around with modules

06:19 <headius> oh I also converted the poms to yaml...they can go back if there's any objections but omg it's so much easier to work with

06:22 <headius> jcodings and bytelist are ready to go

06:45 <headius> on the other hand if you like the yaml thing I'd love to convert all our dependencies to it

06:56 <headius> also: enebo: we discussed still running CI on 8. Does that apply to these libraries or were you mostly concerned about JRuby itself? Ideally if we're testing JRuby on 8 we'll pick up stumbles in the libraries...but only if we call along all paths during testing

06:56 <headius> I suppose it would be best to test everything on 9 and pre-9 if we really intend to support pre-9

07:06 <kares> headius: yaml even for pom.rb? than you can not do arbitrary ruby as needed here and there :) maybe you just mean for pom.xml

07:07 <kares> travis' mvn fine to pick it up as .yml?

08:44 <bomb> guys. jruby is just awesome

08:45 <bomb> it just needs `require 'java'` and the entire java ecosystem is under my fingertips

08:45 <bomb> kudos to everyone who contributes to this project

09:42 <lopex> headius: you said it's pita though :P

19:47 <lopex> enebo: is the release imminent ?

20:10 <enebo> lopex: maybe next week but we should soon

20:12 <lopex> enebo: btw the output from that startup log made me relook at some of that opcode impls

20:12 <lopex> so it seems they helped it a way

20:13 <lopex> startup as the company

20:14 <lopex> enebo: for for recalling https://lgtm.com/projects/g/jruby/joni/snapshot/67efc63430ba234688c007bfd848e57b1c172031/files/src/org/joni/ByteCodeMachine.java?sort=name&dir=ASC&mode=heatmap&showExcluded=false#x572e9de4c9f3378d:1

20:15 <lopex> we shouldnt ask for that casing buffer before possible failure

20:15 <lopex> there might be a ton of such little thingies

20:16 <lopex> which are all hot code

20:17 <lopex> enebo: also I wonder how escape analysis improved since lets say 5 years

20:17 <lopex> allocating this buffer locally would help locality boviously since it's all on the stack

20:18 <lopex> so many questions which would require ton of precise benchmarking

20:21 <enebo> lopex: yeah

20:22 <enebo> lopex: did you remove that casing buffer access

20:22 <lopex> enebo: no ?

20:22 <enebo> "we shouldnt ask for that casing buffer before possible failure"

20:23 <lopex> enebo: I'm speculating at this point, since this pattern might be more widespread

20:23 <lopex> enebo: the buffer is lazily allocated on matched instance

20:24 <lopex> which is a bad thing on so many levels

20:24 <lopex> *s/matched/matcher

20:25 <lopex> so we have a check cost, probably mostly predicted, but locality is bad

20:27 <lopex> enebo: the problem again is the lack of tooling

20:27 <lopex> and how this code might change when new cpus come around

20:28 <enebo> lopex: yeah tooling is tough for measuring perf

20:28 <lopex> enebo: that casing buffer is the elephant in the room

20:28 <enebo> lopex: and obviously not all architectures will be the same

20:28 <lopex> enebo: not to mention bounds checks

20:28 <enebo> you mean cfbuf()?

20:28 <lopex> yeah

20:29 <enebo> could we just AIOOBE and catch and opFail?

20:29 <lopex> what ?

20:29 <enebo> or is opFail not really a failure

20:29 <lopex> it's a backtrack

20:29 <enebo> opFail is a backtrack

20:29 <lopex> yes

20:30 <enebo> oh

20:30 <enebo> ignore that then

20:31 <lopex> enebo: but you see the problem

20:31 <lopex> enebo: or, well, we could allocate it whenever there's ignore case in the pattern

20:32 <lopex> doh

20:41 <lopex> enebo: btw sunday http://www.inf.fh-flensburg.de/lang/algorithmen/pattern/sundayen.htm

20:42 <lopex> so I wouldnt expect wonders in our case

20:43 <lopex> I think bounds checks are killing us in some part