jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Puffball has quit [Remote host closed the connection]
<kares>
enebo: hey! checking - thanks
<kares>
enebo: you're right I forgot to push - got distracted by merge conflicts
<kares>
which I seem to always get while merging to master ... which is mesmerizing since I always tried to keep it clean and to work on 50-stable first
enebo has quit [Ping timeout: 265 seconds]
enebo has joined #jruby
<kares>
enebo: and thanks for the change Result refactoring - guess it wasn't as hard to revert to a reasonable state as I thought :)
<kares>
BTW> as I check the Rails suite before-and-after your change its :
<kares>
... and esp. those are utc time failures are gone - so I am not crazy after-all since as I was looking at it I was quite sure this has been working
<kares>
guess the price for not checking CI enough as we do changes
<kares>
only BC date/time issues left but those are low priority and maybe even working on JRuby master
claudiuinberlin has joined #jruby
olle has joined #jruby
<GitHub26>
[jruby] perlun opened issue #5128: eval in Rack::Builder prints "warning: `frozen_string_literal' is ignored after any tokens" https://git.io/vx1oE
<kares>
hmm ... AR logging once again broken with PS under PG (got [["name", nil], ...]) ... have dealt with this before as well
m4rCsi_ has joined #jruby
desnudop1nguino has joined #jruby
xardion_ has joined #jruby
ChrisBr_ has joined #jruby
lanceball_ has joined #jruby
m4rCsi has quit [*.net *.split]
desnudopenguino has quit [*.net *.split]
xardion has quit [*.net *.split]
ChrisBr has quit [*.net *.split]
lanceball has quit [*.net *.split]
ChrisBr_ is now known as ChrisBr
cremes77 has joined #jruby
kith has joined #jruby
<enebo>
kares: so I have a question about ColumnInfo
<enebo>
kares: I see you transitioning toward String from RubyString
<kares>
enebo: hey! am I :) ?
<enebo>
kares: oh maybe not then :)
<kares>
havent touched the JdbcResult stuff much myself
<kares>
that column code was pbly done by rdubya ... exclusively
<enebo>
kares: I think it was from your large merge
<kares>
which one?
<kares>
I mean which code
<enebo>
I am talking about RubyJdbcConnection.ColumnData
<kares>
ah sorry yes that existed for a long
<enebo>
the way it is written today it depends on a static field which holds RubyString
<enebo>
I made a changeset which reduced this back to RubyString name, and int type and it removed that issue
<enebo>
but pushed responsibility on caller to make sure it was cached (which I think was only done in 2 places)
<kares>
you mean the StringCache
<enebo>
In truth I like the notion of how it is done in JdbcResult because it eliminates n boxes for 2 primitive arrays but with my latest change if you are making AR::Result that second primitive array is source to the column data
<enebo>
yeah stringcache
<kares>
yep I somehow put it up globally so that it leaves past the connection lifecycle
<kares>
there was one place where it lived
<enebo>
I see
<kares>
never liked it but I thought what-the-heck instead of putting it as some internal data on a Ruby piece
<enebo>
basically the idea is over a long running process which makes lots of connection instances we will not need to create new strings
<kares>
yeah
<kares>
esp. since the first thing each coll does is query the model meta-data -> lots of strings
<kares>
* each conn
<enebo>
we can probably leverage dedup strings at this point since I think we require 9k
<enebo>
I am not sure if column strings are frozen in rails 5 though
<kares>
yep we definitely do
<kares>
I think they might be not
<kares>
but I recall frozing them and all was fine :)
<enebo>
heh well that makes it funny we share the same one though
<enebo>
I was talking to tenderlove and he was thinking they should be frozen but our conversation trailed off
edmz has quit [Read error: Connection reset by peer]
edmz_ has joined #jruby
<enebo>
yeah I am thinking we can maybe just call into JRuby and not have this
<enebo>
I just haven't looked to see how public that is in core
edmz_ is now known as edmz
<enebo>
Ruby.freezeAndDedupString()
<kares>
yeah that one makes sense
<kares>
if its there in 9.1 at least
<kares>
which it pbly is and 9.0 is way old?
<enebo>
seemingly on 9.1 and master
<enebo>
kares: yeah 9.0 is EOL and I am not sure if 50 would run on 2.1
jrafanie has joined #jruby
<enebo>
actually I should look it up but I have told one person in the last week 9.0 has been EOL for 2 years
<kares>
enebo: :)))
<kares>
well if you told so
<kares>
there's no way back ...
<enebo>
Rails 5 requires Ruby 2.2.2 or newer.
<enebo>
accoding to edgeguides
<kares>
good - thought so
<kares>
so 9.1 at min
<kares>
that helps ...
<enebo>
heh I don't recall what 9.0.6 was
<enebo>
compatible with Ruby 2.2.x
<enebo>
heheh
<enebo>
well it is not supported
<enebo>
I cannot imagine that 9.0.5.0 would even boot rails 5 and if it did it had enough memory leaks it would be unusable
<enebo>
ah that doesn't work
<enebo>
you need to make a RubyString first
<enebo>
kares: I am going to make 51-stable off of master and master will be for 52 work
<enebo>
rdubya: ^
<kares>
noo this soon :)
<kares>
double merge everything
<kares>
enebo: you'll be looking into 5.2?
<enebo>
kares: so how long do we wait to start working on 5.2
<kares>
not sure till CI is green-ish ?
<kares>
I do not mind but those merges are already demotivating since they do not go clean
<enebo>
kares: ok a compromise will be to make a rails-5.2 branch which will still need merging
<kares>
ah that would be good
<enebo>
kares: so is master and 50-stable much different?
<kares>
at least till we push the current stuff - a first release
<enebo>
so here is another question then, what does releasable state mean for these two?
<kares>
enebo: not sure I wasn't pushing master away - that is why I got surprised about having to do conflicts every time
<kares>
maybe smt you or rdubya did?
<enebo>
kares: I would not think you would see conflicts if we merge regularly
<enebo>
perhaps that was our issue
<enebo>
I have been looking at merging stable-50 -> master -> ...
<kares>
maybe its due some work going master first and than being 'back-ported' in different order?
<enebo>
but if we do this routinely the deltas should be reasonably small and we are not prolifically committing
<enebo>
kares: yeah if there is a 5.1 specific fix which should not be on 5.0 that would be a conflict
<kares>
doing it every time I feel I have done smt - but 2 last ended up in conflicts ;(
<enebo>
kares: so let's talk about this perhaps 50 -> master is ultimately the wrong way?
<kares>
is it?
<enebo>
kares: I don't know. I am asking
<kares>
I think its the good way
<enebo>
kares: ok that was my original thought as well
<kares>
maybe we should not land on master which is meant for 50 as well
<enebo>
kares: yeah I am wondering how much stuff that would be at this point
<kares>
which I guess a few things ended up ... rdubya should know better (seems so to me)
<enebo>
kares: we don't really have tons of issues left in test failures
<enebo>
kares: so logically we will have conflicts for n+1 behavioral changes potentially
<kares>
yeah I am going thru a few of those as we speak
<enebo>
not always but it is inevitable it will happen on occasion
<kares>
okay
<kares>
no biggie than but we shall follow the 50-stable first
<enebo>
but for new point releases how many of these are serious
<kares>
otherwise the double merges will nail us down
<enebo>
yeah I think we should 50-stable -> 51-stable (when it exists) -> master
<kares>
if there's a 51+master branch
<kares>
agreed
<enebo>
I don't think it should have tons of fallout over time because once 50 is mostly correct test wise it will be reported issues
<enebo>
I somewhat feel those issues will tend to ripple through all releases but time will tell
<enebo>
I will merge my work last night to master
<enebo>
I was half waiting for you to comment on it
<enebo>
heh conflict!
<enebo>
I think that is fine though
<enebo>
let's see how bad
<enebo>
A single import statement overlap
<kares>
sounds doable
<enebo>
ultimately I see most conflicts being highly localized as well. Unless it is some big refactoring or a new feature which changes something internal
<enebo>
we should probably make it a point on each logical/temporal set of commits to say we should merge right after landing those commits
<enebo>
Then the person who made the changes will have to deal with the conflicts
<enebo>
If it ends up being something they cannot resolve then they will need to talk to someone
<kares>
+1
<kares>
^^ // cc rdubya
<rdubya>
so we're always supposed to work on 50-stable first? Or just make sure to merge things as close to committing them as possible?
<enebo>
rdubya: on for anything which is across both versions
<enebo>
rdubya: if it is specifically 5.1 fix you do it on that branch
<rdubya>
ok
<kares>
rdubya: guess if you land on master and than pick on 50-stable a big piece you should merge back
<kares>
so the next person doing its merge does not get conflicts he does not know that much about ...
<enebo>
so if you only change on a newer branch you cannot really merge back to master or can you?
<enebo>
if you could that would simplify this process and make it so your commit to the new release did not trip up next person
<kares>
enebo: you mean the mess-up I left you with today?
<enebo>
kares: did you? :P
<enebo>
kares: oh forgetting to push
<kares>
well I push-ed a master merge but not 50-stable :)
<enebo>
that ended up being more your issue than mine
<kares>
that is definitely quite wrong
<enebo>
it happens
<enebo>
I tend to do it more than I care to admit
<enebo>
but a process of always merging through assuming one can is probably a worth the extra noise just so others don't need to say, hmm I wonder if I should include that
<enebo>
I guess I don't know. If I see rdubya commit to master I assume he is making a 5.1 change and it is not meant for 5.0
<enebo>
so that merge would not be hard for me
olle has quit [Quit: olle]
<rdubya>
makes sense
<enebo>
I think we all know the rules now so I don't see an issue...merge forward on any change you make
<enebo>
courtesy merge :)
shellac has joined #jruby
<enebo>
I did not test that merge :P only a single import statement was conflict and it was meant to be zero sum so we shall see
claudiuinberlin has quit [Ping timeout: 255 seconds]
cremes77 has quit [Quit: cremes77]
cremes77 has joined #jruby
<headius>
lopex: I don't remember how to request the Nth character with jcodings
<headius>
the onig naming always confuses me
<lopex>
headius: not in jcodings
<lopex>
headius: StringSupport.nth
<headius>
ok, I'm fixing ByteList to honor toString and CharSequence properly
<headius>
I'll copy that logic over for now
<headius>
seems like it should live in jcodings
<lopex>
yes
<lopex>
long story
lanceball_ is now known as lanceball
lanceball has quit [Changing host]
lanceball has joined #jruby
<headius>
heheh
<headius>
no problem
<lopex>
we talked about moving lots of string support to jcodings
<lopex>
long time ago :P
<lopex>
but it was easier to evolve at that time
<headius>
yeah, these changes will rev bytelist to 2.0.0
<headius>
I'm mostly attempting this now to see how much will break if we want to do it in 9.2
<headius>
we need to fix it to use non-CharSequence methods in any case
<headius>
e.g. realSize instead of length when we want byte length
<nirvdrum>
I think you guys might want to break away from MRI and add variants that are code range aware.
<nirvdrum>
StringSupport.nth on a CR_VALID UTF-8 string can byte hop, for instance.
<lopex>
nirvdrum: encoding and cr is a good candidate for multimethods :P
<lopex>
though through specializations you get something similar