drbobbeaty has joined #jruby
cremes has joined #jruby
cremes has quit [Client Quit]
ebowling has joined #jruby
drbobbeaty has quit [Ping timeout: 255 seconds]
<travis-ci> jruby/jruby-openssl (prefer_trust_certs_4802:80f4b85 by Charles Oliver Nutter): The build is still failing. (https://travis-ci.org/jruby/jruby-openssl/builds/296437894)
<GitHub178> [jruby] original-brownbear closed issue #4915: Stdlib jopenssl/load is Broken on Java 9 https://git.io/vbFHz
claudiuinberlin has quit [Quit: Textual IRC Client: www.textualapp.com]
_whitelogger_ has joined #jruby
me- has joined #jruby
_whitelogger has quit [Ping timeout: 276 seconds]
claudiuinberlin has joined #jruby
Liothen has joined #jruby
shellac has joined #jruby
shellac has quit [Read error: Connection timed out]
shellac has joined #jruby
projectodd-ci has quit []
Liothen has quit [Changing host]
Liothen has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
me- has quit [Ping timeout: 240 seconds]
me- has joined #jruby
nirvdrum has quit [Ping timeout: 248 seconds]
nirvdrum has joined #jruby
Puffball has quit [Remote host closed the connection]
shellac has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xardion has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
xardion has joined #jruby
ebowling has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<GitHub58> [jruby] nomadium opened pull request #4991: Update File#path to raise IOError for files opened with File::Constants::TMPFILE option (ruby-2.5...file-path-now-raises-ioerror-when-tmpfile) https://git.io/vNuXN
shellac has quit [Quit: Computer has gone to sleep.]
claudiuinberlin has quit [Quit: Textual IRC Client: www.textualapp.com]
shellac has joined #jruby
GitHub183 has joined #jruby
GitHub183 has left #jruby [#jruby]
<GitHub183> jcodings/master ae272b1 Marcin Mielzynski: deprecate mbcodeStartPosition
<GitHub183> [jcodings] lopex pushed 1 new commit to master: https://git.io/vNuHz
shellac has quit [Quit: Computer has gone to sleep.]
ebowling has joined #jruby
claudiuinberlin has joined #jruby
rdubya1 has joined #jruby
rdubya has quit [Ping timeout: 255 seconds]
ebowling has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
bbrowning is now known as bbrowning_away
rrutkowski has joined #jruby
rrutkowski has quit [Client Quit]
rrutkowski has joined #jruby
rrutkowski has quit [Quit: rrutkowski]
rrutkowski has joined #jruby
rrutkowski has quit [Client Quit]
rrutkowski has joined #jruby
shellac has joined #jruby
<lopex> enebo: you here ?
<enebo> lopex: hello
<lopex> enebo: not sure if to nail down all that test_regexp issues or take up String#case_cmp
<lopex> joni is clear wrt curent jruby suite
<enebo> lopex: I am not sure what is still an issue but case_cmp is green field right? We have no impl?
<lopex> no impl
<lopex> but jcodings has all the bits
<lopex> now
<enebo> lopex: I would just do that since we need it. We can decide about other errors afterwards
<lopex> enebo: are mspecs tagged the same way mri tests are ?
<enebo> lopex: we are more likely to be able to help on individual issues vs a whole feature
<enebo> lopex: well kind of but a little different
<enebo> lopex: spec/tags/ruby/bleh
<enebo> lopex: you can look in that dir to see the format of adding a tag
<lopex> enebo: so case mapping is more urgent right ?
<enebo> lopex: there is actually an auto tag command too in mspec (don't recall it offhand)
<enebo> is casecmp for 2.5 or 2.4?
<enebo> 2.4 right?
<lopex> 2.4 or earlier
<enebo> lopex: It sounds reasonable to me since it will be a one person job
<enebo> lopex: new features are tough to team on but individual issues generally can be
<lopex> enebo: but it needs newest jcodings
<enebo> lopex: why did you bring that up?
<lopex> case cmp ?
<enebo> lopex: master has never been released so I think we can use the newest unless it is 2.5 behavior
<lopex> so hmm
<enebo> lopex: or you are asking about jruby-9.1.x
<enebo> lopex: I guess I don't understand what your reservation is about updating
<lopex> enebo: well its a little bit tricky now
<lopex> enebo: jcodings involved changes in joni
<enebo> I think we need to start over I have no idea what you are asking nor what your reservations are
<lopex> joni had it's own changes
<enebo> so you updated joni and jcodings for some reasons
<lopex> enebo: boils down to if we want case map we need to upgrade both jcodings and joni
<enebo> the case map stuff is for fixing missing behavior in Ruby 2.4 right?
<lopex> yes
<enebo> Is your concern that you updated to basically Ruby 2.5 data or something?
<lopex> much less than when we talked before
<enebo> I would say we want updated jcoding and joni for Ruby 2.4 support
<enebo> Sicne your updates were for that?
<lopex> among others
<enebo> I guess I don't know why you are uncertain updating it would be a mistake
<lopex> I'm not uncertain
<enebo> We are talking about master and probably ruby-2.5 but not jruby-9.1
<lopex> well, not entirely
<enebo> I would just update for both master and ruby-2.5 unless you have a specific reason why that will cause a problem
<lopex> but the features I'm talking about are 2.5
<lopex> enebo: exactly
<enebo> oh well then for now at least then just update ruby-2.5
<lopex> no known issues atm
<enebo> If jcoding and joni will not work with master as is for JRuby 9.2 then that is probably a problem we will need to find a solution for
<lopex> enebo: but I remember you where concerned about my uncertainty
<lopex> enebo: how close is the next release ?
<enebo> but if it is just not being sure if current joni/jcodings will work on master we should add it and see
<enebo> lopex: for 9.2 at earliest next month
<enebo> lopex: at this rate it feels like we will never finish :)
<enebo> lopex: but the sooner you land new stuff the sooner we figure out if there is a problem
<enebo> lopex: I was asking before about risks/concerns but you were unsure. It seems you are still unsure
<lopex> enebo: so just release them
<enebo> lopex: we should just do it and see
<enebo> lopex: yeah
<enebo> lopex: major release perhaps though
<enebo> lopex: jruby-9.1 is Ruby 2.3 and I don't want a lot of risk being added there
rrutkowski has quit [Remote host closed the connection]
claudiuinberlin has quit [Quit: Textual IRC Client: www.textualapp.com]
rrutkowski has joined #jruby
<lopex> enebo: er, you confused me now
<enebo> lopex: we have 3 branches
<lopex> yeah, we'll never finish
rrutkowski has quit [Remote host closed the connection]
<lopex> we cannot put that straight in this conversation
<lopex> shall we start over ?
<enebo> lopex: sure
<lopex> my claim is
<lopex> joni/jcodings should not have any breaking changes across any jruby release
<lopex> that update
<enebo> ok
<lopex> second
<lopex> are you concerned about 2.5 mri changes that joins/jcodings has ?
<lopex> *have
<enebo> lopex: I just ask people who do work what they think the risks are
<enebo> lopex: if they do not feel there are many then I feel better
<enebo> lopex: so your first claim just now basically tells me you are not very concerned about breaking changes
<enebo> lopex: but I think we confused each other earlier
<enebo> lopex: most of what changes in both packages are largely corrections to data and some bug fixes and new features. earlier Ruby's will not see the new features unless they need them then that is fine. Bug fixes likely are not really an issue either (we do sometimes want to be bug for bug but I doubt many people want invalid encoded data). same for data updates.
<lopex> 9.1 is what compat ?
<enebo> 2.3.x
<lopex> 9.2 ?
<lopex> 2.4 ?
<enebo> 2.4
<lopex> well, so let's go 9.2 whith all that changes
<enebo> so it sounds like you should just point release both and put it on all three branches
<enebo> oh hahahaha
<lopex> er, I was serious :P
<enebo> "lopex: joni/jcodings should not have any breaking changes across any jruby release"
<enebo> lopex: so this seems like you changed your mind
<lopex> enebo: well the unicode data
<lopex> not sure how it breaks anything
<lopex> but not wrt impls
<enebo> lopex: are those data changes data fixes?
<lopex> enebo: wrt unicode, range extensions and range additions
<enebo> range extensions means broader range of data for some encodings?
<lopex> yes
<lopex> only for unicode
<lopex> actully
shellac has quit [Quit: Computer has gone to sleep.]
<lopex> *actually
<enebo> lopex: so in Ruby 2.3 someone might try and use something in that range and it will not think it is valid right? but it will in 2.4 or later?
<lopex> enebo: unicode doesnt like to break things too
<lopex> yes
<lopex> but not in hte reverse
<enebo> lopex: Trying to think about how that will break anything though
<lopex> yeah
<lopex> enebo: welllll
<enebo> I mean if anything it is something someone would report against us unless they also run on MRI
<enebo> then they would maybe realize it is a 2.3 bug and not a JRuby bug
<lopex> enebo: we can regenerate that data for 2.4 no problem
<lopex> enebo: and spin 2.4 jcodings etc
<enebo> lopex: I am just thinking about risk of having more up to date unicode data
<lopex> well
<enebo> lopex: If we add newer data to 9.1 than MRI 2.3.5 has will that cause bug reports
<lopex> the it's bugs
<lopex> 2.4 bugs
<lopex> *then
<lopex> oh hell
<lopex> I'll show you something
<enebo> lopex: so 2.4 updated data but had some mistakes?
<enebo> lopex: which they then fixed in 2.5 but not 2.4?
<lopex> enebo: I thought we switched from talking about data
<lopex> to code
<enebo> lopex: I keep thinking about this from the standpoint of what will cause more issue reports
<enebo> lopex: oh sorry ... ok just to be clear... you are not concerned with newer data
<enebo> To me the data side seems like people will not mind more accurate encoding data
<lopex> enebo: to the point user code is not prone
<lopex> enebo: we definitely wont have any bugs
<enebo> lopex: ok so to this end we could introduce a bug in behavior but that is always possible
<lopex> the data is take from mri binaries
<lopex> as always
<enebo> lopex: sure but we don't version it in jcodings
<enebo> or do we?
<lopex> we dont have to
<lopex> we can generate from mri 2.4
<lopex> as I mentioned earlier
<enebo> lopex: or 2.5?
<lopex> now it's 2.5
<enebo> ok
<lopex> but it can be whatever down to 2.2. ?
<lopex> or something
<enebo> and 2.5 data in 2.4 and 2.3 should be ok because it is just fixes to the data
<enebo> and some new feature data but that does not matter for 2.3 if 2.3 does not use that new feature data
<lopex> not new feature data
<lopex> just ranges
<lopex> defined by unicode
<enebo> so JRuby 9.1.x might start saying some byte sequences are properly encoded UTF-8 data (just an example) that a previous 9.1 release did not but most people will actually want that behavior
<enebo> ok
<enebo> most == all
<lopex> ranges are just for character types
<lopex> \p{foo}
<enebo> ah ok
<enebo> So possibly someone's regexp behavior will change but it will be more correct
<lopex> foo is a set of codepoints defined by set of ranges
<lopex> yes
<enebo> I am just trying to think about what will change and if that will cause issues
<lopex> paranoidaly it can
<lopex> but those where not defined before so it must have been bugs in previous code
<lopex> or
<enebo> ok
<lopex> somewhat vulnerable in other ways
<lopex> it's just ranges
<enebo> ok it sounds like the data updates are ok
<enebo> behaviorally you just pointed to updates to oni which no doubt if we learn of them then they get fixed in the next point release
<lopex> otherwise, joni has dozens of issues fixed
<enebo> unless newer oni is super unstable I guess that is not a big concern
<enebo> and likely it will make our regexps work better in 9.1
<lopex> enebo: because you're pointing to "change" definitions which I cannot address
<enebo> unless it adds some non-2.3 feature outright
rrutkowski has joined #jruby
<lopex> of course there's some set of incompatible changes
<lopex> you're definitely referring to real code in the wild
<lopex> which can have any sort of issues
<enebo> lopex: yeah of course
<lopex> but they're either reaaaly exceptional ofr have to be crafted
<enebo> lopex: We cannot guarantee anything
<enebo> lopex: ok so just update both as point releases and add to all three branches
<enebo> lopex: It really does not sound like we have a lot to worry about
<lopex> at last, we got to that point :P
<enebo> lopex: yeah I just ask questions and I think you thought I was making a statement
<lopex> yeah sure
<lopex> I have no problem with taht
<enebo> lopex: yeah cool
<lopex> poh btw
<lopex> enebo: want to see what \X in regexp expands to ?
<enebo> lopex: I don't know...do I? :)
<lopex> enebo: that grapheme clusters
<lopex> enebo: and we really match mri here
<enebo> yay!
<lopex> enebo: that's the ranges we;ve been talking about for example
<lopex> enebo: you'll find it funny https://i.imgur.com/xPSxBDT.jpg
<enebo> make sense
<lopex> enebo: you think fuzzing regexps might be cool wrt https://github.com/mifmif/Generex ?
<lopex> for testing
<enebo> lopex: yeah probably most useful for finding very slow matching
<enebo> lopex: although perhaps that is a issue with making the string from that library
<enebo> lopex: since they must verify it matches
<enebo> lopex: but I bet a library like this would expose some bugs if you made enough strings
<lopex> as always
<lopex> I wonder if quickcheck has something for this
<lopex> btw Oracle seems to be demoing http://whiley.org/
<lopex> enebo: wrt verification
<lopex> but I learned a few channels left SPARK also does termination
<lopex> so regexp also sohuld have specs
<lopex> enebo: oh there's also that new opt not enabled now
<lopex> enebo: if strings cr is 7bit go singlbyte ops
<lopex> for now it worked for years for singlebyte encodings
<lopex> no sure how dangerous it is