lucasb has quit [Quit: Connection closed for inactivity]
vietcube has joined #jruby
vietcube has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
_whitelogger has joined #jruby
snickers has joined #jruby
rusk has joined #jruby
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
snickers has quit [Quit: Textual IRC Client: www.textualapp.com]
whitingjr has joined #jruby
whitingjr has quit [Read error: Connection timed out]
whitingjr has joined #jruby
rusk has quit [Read error: Connection reset by peer]
rusk has joined #jruby
lucasb has joined #jruby
whitingjr has quit [Remote host closed the connection]
whitingjr has joined #jruby
<enebo[m]> lopex: can you make an alias for "UTF8" to "UTF-8" in jcodings. Enough people keep hitting this where having them all correct their environments is more work than just having an alias
<enebo[m]> lopex: I don't really see the harm of it either
whitingjr has quit [Ping timeout: 268 seconds]
<headius[m]> Missing alias?
<headius[m]> I forget if that list is generated
<lopex> or was is class level alias ?
<enebo[m]> lopex: it did seem like we had this talk before :)
<lopex> ah, I recall
<lopex> the other way is more problematic
<enebo[m]> lopex: it is in response to encoding: UTF8 and also VMs passing that in file.encoding=UTF8
<lopex> it depends where the lookup happens
<lopex> so if it goes through alias machinery
<enebo[m]> Java has a couple of libraries which erroneously have that string also so I think we may continue to infrequently get the report
<enebo[m]> lopex: Encoding newEncoding = runtime.getEncodingService().loadEncoding(name);
<lopex> would that work via alias ?
<enebo[m]> This is what the pragma does
<enebo[m]> I don't know where we get it from file.encoding
<enebo[m]> lopex: so that alias is already updated to be used on JRuby (e.g. we released since you made that commit)?
<lopex> enebo[m]: but I remember there was an issue where someone called jcodings directly too
<lopex> wait a minute
<enebo[m]> lopex: I don't care as much about that (at least in caring that 9.2.8.0+ won't get this report again)
<lopex> enebo[m]: can you try that one locally ?
<enebo[m]> doh yeah :)
<enebo[m]> jruby -J-Dfile.encoding=UTF8 -e 'p "a".encoding'
<enebo[m]> #<Encoding:UTF-8>
<enebo[m]> lopex: looking good
<lopex> enebo[m]: so we need a jcodings release now
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
whitingjr has joined #jruby
rusk has quit [Remote host closed the connection]
shellac has joined #jruby
whitingjr has quit [Ping timeout: 245 seconds]
subbu is now known as subbu|lunch
shellac has quit [Quit: Computer has gone to sleep.]
<lopex> enebo[m]: let me clarify, was that with that alias just added ?
subbu|lunch is now known as subbu
<enebo[m]> lopex: my test output was from master which will be 9.2.8.0 so that alias must be from a jcodings release since we do not snapshot those libs any more
<lopex> enebo[m]: then I'm confused
<enebo[m]> lopex: 1cb4a0e9 (Marcin Mielzynski 2017-12-15 01:24:36 +0100 37) "UTF-8" => "UTF8",
<enebo[m]> It is too old to explain it
<lopex> enebo[m]: it's from generation script rewrite
<lopex> that commit
<lopex> and it's only a mapping to java classnames
<enebo[m]> jruby -J-Dfile.encoding=UTFFOOBAR -e 'p "a".encoding'
<enebo[m]> lopex: so we must default to utf-8 in case it cannot find it
<lopex> so there's a fallback
<lopex> enebo[m]: can you try with that todays commit ?
<enebo[m]> lopex: reporter said master works for them so we probably added something at some point
<lopex> but then we'd have to make sure tu turn off fallbacks
<enebo[m]> lopex: yeah I would like to know why this is happening
<lopex> but it's no a jcodings thing afair
<enebo[m]> lopex: fwiw only windows seemed to have issues with UTF8 with only j9 or file.encoding=UTF8
<enebo[m]> lopex: but apparently j9 is working on windows now with master
<lopex> it must be jruby then
<enebo[m]> lopex: yeah we must have did something to encoding processing in last half a year
<enebo[m]> lopex: yeah
<lopex> so, encoding service ?
<enebo[m]> lopex: I will update jcodings though
<enebo[m]> probably?
<lopex> enebo[m]: since encoding service is aware of jcodings aliases it might go different path
<lopex> yeah
<lopex> enebo[m]: I mean, it should go through findEncodingOrAliasEntry
<lopex> but I dunno where any fallback is if any
<enebo[m]> ok in May there were two commits (one appears to just correct something from first) related to processing encoding for default external on windows
<lopex> but before findEncodingOrAliasEntry or after ?
<enebo[m]> It is for filesystem encoding during initCore
<lopex> does it use encoding service ?
<enebo[m]> which if it cannot find the encoding it defaults to defaultExternal
<enebo[m]> if (Platform.IS_WINDOWS) {
<enebo[m]> setDefaultFilesystemEncoding(encodingService.getWindowsFilesystemEncoding(this));
<lopex> hmm, then todays alias might change it
<enebo[m]> it does have the potential but I think it should always end up as UTF-8 normally
<enebo[m]> unless you make -E :S-JIS or something
<enebo[m]> but if you specify that and pass in file.encoding=UTF8 then I suspect you have more env issues than us having compat issues
<lopex> enebo[m]: but I recall another issue where user asked jcodings to load "utf-8" and there isnt any in https://github.com/jruby/jcodings/blob/master/src/org/jcodings/EncodingList.java#L200
<lopex> so that's the other edge
<lopex> but let's not go into that now
<lopex> so I guess it's unnecessarily complicated
<lopex> since
<lopex> there's that map in generation script
<lopex> so that's one mapping
<lopex> then there's encoding db which has names mapped to entries
<enebo[m]> I honestly don't fully understand how jcodings does this. I knew there were aliases but I don't know how people are suppose to search to get an encoding. I am satisfied with EncodingService doing the right thing
<enebo[m]> (although I do bypass in lexer and get US ASCII and UTF8 directly
<lopex> jcodings itself is not aware of aliases
<enebo[m]> but we always consume both of those
<lopex> it just keeps alias list, thats all
<lopex> well, I'll look into it
<enebo[m]> lopex: so consumers need to call alias helper to get real name and then get the encoding or something like that?
<lopex> enebo[m]: if they use jruby's encoding service it should be ok now
<lopex> enebo[m]: jcodings just maintain list of encodings and aliases
<lopex> but encoding service resolves aliasing
<enebo[m]> lopex: ok so if I release jcodings we are good
<lopex> enebo[m]: well, it sohuld break anything
<lopex> *shouldnt
<lopex> enebo[m]: but what I was telling you now is just a theory :P
<lopex> with some grounds though
<enebo[m]> lopex: The alias will affect much more than filesystem encoding settings on windows as well so I think generally it will reduce any issues in the future other than the opposite direction (someone using it in JRuby then realizing it does not work in MRI)
<lopex> to test that, we'd need a repro which foes through findEncodingOrAliasEntry
<enebo[m]> lopex: I am going to make sure it works with pragma and -E too
<lopex> *goes even
<lopex> enebo[m]: when jcodings was extracted from joni there wasnt any alias concepts yet
<lopex> so that's a historical burden now
<lopex> but alias resolving should probably go into jcodings
<lopex> I recall there was some problem with jruby runtime needed at some point
<lopex> since mri has it all in the same code base, they dont care
<lopex> yeah, all alias phrases in oniguruma repo from that time are ruby alias methods
<lopex> enebo[m]: btw this one is frustrating https://github.com/jruby/joni/issues/44
<enebo[m]> lopex: I read that one but I did not fully follow. It almost sounded like a bug in onigmo ends up terminating that case?
<lopex> enebo[m]: yeah, but not certain
<lopex> it may be the case we get negative and got different route on compare
<lopex> enebo[m]: but the problem is
<lopex> enebo[m]: you can call onigmo search/match always with all those ags
<enebo[m]> I really wish java additionally had unsigned types
<lopex> *ags
<lopex> p/end start/range
<lopex> also there's a global pos we dont support now
<lopex> and it affects complicated search thing
<lopex> just before entering match
<lopex> enebo[m]: that quick fix will make us match onigmo, but there's something wrong indeed
<lopex> joni assumes that once a matcher is created p/end wont change
<lopex> you can rerun on a matcher with start/range changed
<lopex> they break that rule
<lopex> enebo[m]: ^^
<enebo[m]> maybe it was never really a rule?
<lopex> enebo[m]: yeah, but there's only two calls to onig_search in mri's codebase (apart from strscan.c)
<lopex> but api joni prvides now, does not allow those usages
<lopex> *joni api
<lopex> enebo[m]: but what's even more confusing it comes from https://github.com/ruby/ruby/blob/master/re.c#L1561
<lopex> so that rule is obeyed
<lopex> well, dont bother looking at this now though
<lopex> hmm, it might be that their pos/range is that one is relative and the other is not
<lopex> anyhow, I can trigger onigmo going the same path, and it's not an infinite loop
<lopex> I dont see how skip searches are smart enough for look aheads