Freeky is now known as Freaky
<GitHub119> [jruby] jakago opened issue #4677: __FILE__ is not available in BEGIN section https://git.io/vHjr3
Guest71283 has quit [Remote host closed the connection]
me has joined #jruby
me is now known as Guest50953
shellac has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vtunka has joined #jruby
drbobbeaty has joined #jruby
rdubya has joined #jruby
bbrowning_away is now known as bbrowning
swills has quit [Quit: Leaving]
dfr has quit [Remote host closed the connection]
_whitelogger has joined #jruby
chat has joined #jruby
chat is now known as Guest87679
chat_ has quit [Ping timeout: 240 seconds]
chat____4 has joined #jruby
Guest87679 has quit [Ping timeout: 240 seconds]
vtunka has quit [Quit: Leaving]
<rdubya> Hey all, I'm planning to work on getting the postgres and mssql adapters in activerecord_jdbc_adapters compatible with Rails 5/5.1 and I'm not sure of the best approach to take
<rdubya> I noticed there is a branch for Rails 5 and a separate branch that looks like it has some 5.1 work being done on it
<rdubya> was just wondering which would be the preferable one to work off of
<enebo> rdubya: hello
<enebo> rdubya: I would use rails5 as it is the one I had been working with for mysql work
<enebo> rdubya: the other thing to note is for rails5 the plan was to strip out all pre Rails 5 conditionals/logic so that is ok to do
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
shellac has quit [Quit: Leaving]
camlow325 has joined #jruby
hobodave has joined #jruby
hobodave has quit [Quit: Computer has gone to sleep.]
hobodave has joined #jruby
<rdubya> sorry for the delay in response, I'll go off the rails5 branch, and keep an eye out for older stuff that can be removed
<enebo> rdubya: cool...thanks for helping!
<rdubya> my employer decided it was worth letting me spend some time on it so that we can get upgraded to Rails 5, so I'll hopefully be able to pick at it for a few hours each week
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
tenderlove has quit [Remote host closed the connection]
donV has joined #jruby
<GitHub180> [jruby] donv opened issue #4678: Prepending a module to a module extended by a class gives NPE https://git.io/vQvLb
hobodave has quit [Quit: Computer has gone to sleep.]
hobodave has joined #jruby
hobodave_ has joined #jruby
hobodave has quit [Ping timeout: 260 seconds]
rdubya1 has joined #jruby
bruceadams_ has joined #jruby
electrical_ has joined #jruby
donV_ has joined #jruby
donV has quit [*.net *.split]
rdubya has quit [*.net *.split]
bruceadams has quit [*.net *.split]
electrical has quit [*.net *.split]
enebo has quit [*.net *.split]
clayton has quit [*.net *.split]
donV_ is now known as donV
electrical_ is now known as electrical
bruceadams_ is now known as bruceadams
clayton has joined #jruby
rdubya1 has left #jruby [#jruby]
rdubya1 has joined #jruby
enebo has joined #jruby
yopp has quit [Ping timeout: 240 seconds]
yopp has joined #jruby
camlow325 has quit [Quit: WeeChat 1.5]
rdubya1 has quit [Quit: Leaving.]
rdubya has joined #jruby
rdubya has quit [Client Quit]
rdubya has joined #jruby
<GitHub61> [jruby] enebo pushed 1 new commit to master: https://git.io/vQv6S
<GitHub61> jruby/master 4323f93 Thomas E. Enebo: Make Date._strptime loaded as a native ext and make map to hash conversion...
<GitHub22> [jruby] enebo closed pull request #4676: Implement key conversions with symbol by Java within Date._strptime (master...implement_key_conversions_with_symbol_in_java) https://git.io/vHhxK
donV has quit [Quit: donV]
rdubya has quit [Quit: Leaving.]
rdubya has joined #jruby
rdubya has quit [Client Quit]
hobodave_ has quit [Quit: Computer has gone to sleep.]
<GitHub70> [jruby] enebo pushed 1 new commit to master: https://git.io/vQvSv
<GitHub70> jruby/master 65e1495 Thomas E. Enebo: Remove intermediate Map for Hash directly. This was pretty minor change and it...
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo> lopex: you around
<enebo> nirvdrum: perhaps you can help me too
<lopex> enebo: hiya
<enebo> ext/date/date_strptime.c parses Ruby string for format but I see zero logic for handling multibyte characters
<lopex> 2.4 ?
<enebo> I guess all format strings must be ascii-compatible but can they really just index across a char * and pretend if they find a '%' it is one?
<enebo> lopex: for the sake of this conversation I do not think it matters...from whatever version they started having a native impl of _strptime
<enebo> HEH I am on that gcc guys branch which was off of 2.4 but I do not think they changed this impl
<lopex> enebo: hmm, maybe they wanted to reuse ruby hashing and gc
<enebo> lopex: in case the question is not clear enough can they assume any ASCII character they see from bumping a pointer is actually an ASCII char
joevandyk has quit [*.net *.split]
jimbaker has quit [*.net *.split]
eregon has quit [*.net *.split]
knowtheory has quit [*.net *.split]
herwin has quit [*.net *.split]
herwin has joined #jruby
<enebo> lopex: sorry I don't understand what you said at all
jimbaker has joined #jruby
<lopex> and also some ruby error handling ?
knowtheory has joined #jruby
eregon has joined #jruby
<enebo> lopex: they do not use mbclen or any methods to appropriately walk characters even though this is the contents of RSTRING data...can they really just pointer walk looking for ascii chars?
<lopex> yes
<enebo> lopex: ah ok can you explain why?
<lopex> but they use set_hash("leftover", s) etc there
<enebo> lopex: yeah because they set results in a hash
<lopex> so they're reusing some core functionality there
<enebo> lopex: but that does not seem relevant to me in any way
<lopex> but wrt walking, sure
<enebo> lopex: the parsing itself completely ignores character boundaries and maybe it works but I don't quite get how it can completely work
<enebo> maybe it is because it is always '%' followed by some ascii char and no other ascii compat mbc can have that sequence?
<lopex> enebo: lol look at that 'Z'
<enebo> lopex: you mean lazy init code?
<enebo> lopex: so that code even assume it is matching against a US-ASCII string
<lopex> yeah
<enebo> lopex: so maybe strptime does not allow mbc format string
<lopex> since string ctors are all useascii
<enebo> lopex: ok I guess I don't know what this function is now
<enebo> lopex: I guess it only accepts valid chars and white space
<lopex> ?
<enebo> for some reason I thought you could add other chats
<enebo> chars
<enebo> in my head I thought you could put 'frogger %h %d' and have it split it all out
<lopex> well, that function is quite old
<enebo> jruby -rdate -e 'p Date.strptime("2001 foo 01", "%Y foo %m")'
<enebo> so can I make string to be parsed any encoding and then put a really exotic char which makes it all go boom?
<enebo> Or will it complain if I mbc with utf-8 or something?
rdubya has joined #jruby
rdubya has quit [Client Quit]
<enebo> jruby -rdate -e 'p Date.strptime("2001 \xeffffoo 01".force_encoding("UTF-8"), "%Y \xeffffoo %m")'
<enebo> haha
<enebo> yeah it works but this seems like it could break
<lopex> enebo: I think it will fail
<lopex> default: if (str[si] != fmt[fi]) fail()
<enebo> it works
<enebo> #<Date: 2001-01-01 ((2451911j,0s,0n),+0s,2299161j)>
<lopex> so it follows fmt like in binary
<lopex> methinks ?
<enebo> lopex: but if I can find a extension char which has a later byte which ascii '%' something odd could happen right?
<enebo> lopex: since they treat it all as ascii
<lopex> enebo: hmm
<lopex> enebo: prepared one ?
<enebo> FE is hex for % right
bbrowning is now known as bbrowning_away
<lopex> what ?
<lopex> enebo: FE has msb bit set so it would be a head of an utf8 char
<lopex> enebo: if they skip any of >127 then they will fail
<enebo> \x25 is %
<lopex> but if both string and fmt have unicode then is interesting
<lopex> *its
<enebo> jruby -rdate -e 'p Date.strptime("2001 \x041".force_encoding("UTF-8"), "%Y \u0425m")'
<enebo> lopex: this did not work but hopefully you can see what I was trying to do
<enebo> hmmm \x is weird
<lopex> depends how it interprets fmt right ?
<enebo> lopex: yeah exactly my question though
<enebo> lopex: since second half of that cyrillic char is % if you pretend it is ascii then it will see this as %m
<enebo> lopex: since format seems to only be treated as ascii string I think it parses this very weirdly
<enebo> lopex: the actual string it matches against perhaps is not possible to make though
<lopex> enebo: what about a nonascii encoding for fmt ?
<lopex> I mean non compatible
<enebo> lopex: yeah I guess I would assume it just looks for bytes which happen to be ascii values
<enebo> lopex: perhaps they just don't care...no one will intentionally do it and so no one will inadvertently do it
<lopex> so then we return to the question if you could come up with some utf-8 char tails which would confuse that
<enebo> lopex: yeah
<enebo> lopex: at this point I think it is likely possible but I can sort of see why they do not care
<enebo> lopex: but it feels really weird
<lopex> I guess they will just fail
<lopex> so no security concern I guess
<lopex> and they fail fast there
<enebo> lopex: yeah the patterns being forced to us-ascii probably means it will never match
<enebo> lopex: or even if you can find one it will never be done
<enebo> and I see no way to walk off a string since it is a single byte thing (us-ascii pretend time)
<lopex> serious sec concerns are there when you begin to use mbclen functions
<enebo> lopex: but everything else in MRI uses them
<lopex> unicode can be a vector of lots of attacks
<lopex> :P
<lopex> afaik there was normalization attacks possible in previous unicode version
<enebo> lopex: nothing surprises me
<lopex> oh that was that expanstion factors afaik
<lopex> normalizations lowers the maximum lengths
<lopex> it's night here so forgive me being slow now
<lopex> and just opened a beer
<lopex> this one has cool smell, but not enough body for me
<enebo> nice
<enebo> I have not seen that one
<enebo> lopex: someone needs to make an option for jflex to work with joni and byte arrays
<enebo> lopex: that new strptime code uses Reader and java characters
<enebo> lopex: as such it has a decent penalty
<enebo> The lexers themselves are not huge so it might be worth hand writing them
<enebo> but a jflex which worked with bytes would make it so much easier
<lopex> enebo: I wonder if java9 will expose some byte[] thingies
<lopex> wrt compact strings
<lopex> they might specialize some of it right ?
<enebo> lopex: who knows...it is only 7bit ascii more or less
<lopex> but I dont think there's any byte[] lexer for java
<enebo> lopex: but will charAt just be simple and thus make it faster in cases where it is always ascii?
<lopex> enebo: afaik it might use shifts there depending on repr
<enebo> lopex: it also assumes Java9 ever is release :P
<lopex> enebo: there's this coder field https://www.javagists.com/compact-strings-java-9
<lopex> enebo: you mean endless vetos ?
<enebo> lopex: well the module thing has not been super great community-wise but just in general Java 9 has been taking a long time to get finished
<lopex> yeah, lots of potentially invasive things
<lopex> and criticism
<GitHub187> [jruby] muga closed pull request #4675: Cache RubyDateParser object in ThreadContext to reduce the cost of object creations (master...cache_rubydateparser_in_threadcontext) https://git.io/vHhAI
<enebo> lopex: the bigger something is I think the more uses it has
<enebo> lopex: afk...