Puffball has quit [Remote host closed the connection]
dave____ has joined #jruby
dave__ has quit [Ping timeout: 260 seconds]
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
olle has quit [Quit: olle]
vtunka has quit [Quit: Leaving]
olle has joined #jruby
vtunka has joined #jruby
<kares>
headius: ok - thanks, so we'll need to figure it out anyways now that even jossl tests got broken
<kares>
AR-JDBC cool, some folks reached out and I have planned a week or two to help out e.g. with the master merge and some tuning
<kares>
assuming that there will be a 5.0 release (or at least pre-release) by than?
raeoks has joined #jruby
<kares>
or you guys shooting directly for a release or will you do a pre-release (asking since in case we leave merge/tuning to later it might make more sense to only do pre/beta)
<kares>
although it deserver a release even as is :) there's more Rails tests passing than ever before
projectodd-ci has joined #jruby
shellac_ has joined #jruby
dave____ has quit [Remote host closed the connection]
olle has quit [Quit: olle]
dave__ has joined #jruby
dave__ has quit [Remote host closed the connection]
<rdubya>
headius: I don't remember seeing that exception before
olle has joined #jruby
dave__ has joined #jruby
dave__ has quit [Ping timeout: 250 seconds]
<rdubya>
headius: will the datetime fixes make it into 9.1.14? I'm hoping they will fix one of the remaining test failures for the arjdbc postgres adapter
shellac_ has quit [Quit: Computer has gone to sleep.]
dave__ has quit [Remote host closed the connection]
swills has quit [Remote host closed the connection]
dave__ has joined #jruby
vtunka has joined #jruby
joast has quit [Quit: Leaving.]
joast has joined #jruby
<headius>
rdubya: I'll check on that
<headius>
kares: there will defeinitely be a 5.0 release before RubyConf...however many tests are passing
<headius>
remaining known failures will just be known issues we'll fix in an update, but most things will work fine
shellac_ has joined #jruby
<GitHub126>
[jruby] headius pushed 2 new commits to jruby-9.1: https://git.io/vFB2H
<GitHub126>
jruby/jruby-9.1 29890d2 Benoit Daloze: Use the original definition for Time#to_date
<GitHub126>
jruby/jruby-9.1 7574431 Benoit Daloze: Use the original definition for Time#to_datetime
<headius>
rdubya: I think those are the two relevant commits but check my work
dave__ has quit [Remote host closed the connection]
nowhereFast has left #jruby [#jruby]
<rdubya>
headius: cool I'll check it out
dave__ has joined #jruby
dave__ has quit [Remote host closed the connection]
<headius>
enebo: so I have a fix for the encoding thing
vtunka has quit [Quit: Leaving]
<headius>
sqlite does columns via a query so I had to patch a few places that do newUnicodeString to do newInternalFromJavaExternal
<headius>
at first I thought the base columns impl in RubyJdbcConnection was getting called, but it was not for sqlite3. I have a patch for that as well but have not tested mysql
<enebo>
headius: ok
<enebo>
I voted!
<headius>
bravo
dave____ has joined #jruby
dave____ has quit [Ping timeout: 240 seconds]
<headius>
enebo: ok so a question
<headius>
I hate minimal patches for sqlite3 and mysql, confirmed both
<enebo>
voting is easy
<headius>
hate=have
<enebo>
HATE
<enebo>
I was teasing out the true meaning
<enebo>
I generally love minimal patches to anything
<headius>
I don't feel right about blindly changing all the other string creation the same way
<enebo>
yeah I was wondering about that
<enebo>
headius: so a thought is whether there are other EUC-JP tests in AR test suite
<enebo>
headius: perhaps we somehow do that somewhere
<headius>
so the interesting bit here is that this patches both schema strings and result strings
<headius>
since sqlite runs a query
<headius>
perhaps what I have is reasonable: I patch readerToRuby, stringToRuby, and xmltoRuby to use internal encoding but I don't go speculating
<enebo>
hmm
<rdubya>
headius: I don't currently have my environment set up to be able to compile JRuby so I can't verify, but I'm wondering if those changes fix the whole issue
<enebo>
rdubya: you do have jdk installed right?
<enebo>
rdubya: we should get you on the compile train
<headius>
woo woo
<enebo>
rdubya: with jdk you just do ./mvnw and it bootstraps maven and it builds ... LIKE MAGIC!
<rdubya>
lol
<enebo>
rdubya: but seriously all you need is jdk
<rdubya>
ok let me try it out
<enebo>
rdubya: and our repo cloned to jruby-9.1
<enebo>
rdubya: release likely tomorrow for 9.1.14.0 so anything which helps confirm anything is useful
<rdubya>
ok I'll see if I can get it up and running most of my afternoon is meetings unfortunately but hopefully i can get some done between them
<enebo>
rdubya: yeah and not a huge issue if you can't
Puffball has joined #jruby
<headius>
enebo: my fixes are in
<headius>
I'll look at the full suite and see what else looks good
<enebo>
headius: nice I will pull and see the magic!
<headius>
we need to do a pass to clean up CI also...9.1 looks a little iffy
<enebo>
headius: one thing which would be super super nice would be to figure out which tests are causing our intermittent failures
<headius>
yeah
<headius>
wouldn't it though
<enebo>
headius: I have a start on it and can share what I know and scripts
<enebo>
SCRIPTS
<headius>
yeah mysql and sqlite3 are both green for base_test now
<headius>
the problem was that we don't set status to aborting when we proceed to propagate the thread kill
<enebo>
hahaha
<enebo>
headius: I only laugh because it makes me nervous :)
<headius>
I found a few cases where we're not *preserving* the aborting status, like if I printed it out the IO threading would set it back to run
<enebo>
I guess setting a status earlier is ok...it signals intent
<headius>
but I'm not going to hunt for those cases
<headius>
not earlier...at all
<headius>
I think when I ported over the thread event logic the aborting status went missing
<enebo>
headius: oh well I think this makes sense we are intending to kill so it is supposedly going to abort
<headius>
right
<enebo>
headius: but aborting does not mean it may not still be running right?
<enebo>
headius: it just means we tried and will wait and see
<headius>
the missing bit is that it should *stay* aborting regardless of what you do to it, and never go back to run...but I don't have any of that in place
<headius>
aborting means it's running under kill
<headius>
so it's on its way out
<headius>
the tx logic basically does if Thread.current.status == 'aborting'; rollback
<headius>
note that normal exceptions will always rollback...this is just for the transaction ensure block...this is how it knows the thread is aborting due to something non-exceptional, but it should still roll back
<headius>
enebo: so, how do you feel for 9.1.14 then
<headius>
this could be a problem for people expecting killed threads to roll back transactions
<headius>
but people are asking for a lot of other problems if they're arbitrarily killing threads doing AR
<enebo>
headius: so yeah is that a risk?
<enebo>
I guess I wonder what people would use this status for
<enebo>
in AR it means rollback but then again this thread might still be trying to finish it's commit
<enebo>
or does it
<enebo>
kill specifies it wants to abort
<headius>
I think the risk is pretty low since this only fires on forcibly-killed threads
<enebo>
but it might still be completing database operation
<enebo>
a rollback should not occur until this thread is dead though
<enebo>
so why is abort checked?
<enebo>
or is this just the test?
<headius>
no, this is AR transaction method
<enebo>
headius: so it starts to roll back if it sees thread in abort
<headius>
look at activerecord/lib/active_record/connection_adapters/abstract/transaction.rb
<enebo>
headius: but abort just means in this case the thread was requested to kill
<headius>
there's an ensure to commit the transaction, but first it checks if the thread is aborting
<headius>
yes, that's it
<enebo>
headius: so it might still be working on an operation
<headius>
if the thread is aborting, it rolls back instead of committing
<headius>
we were just going right on through and committing
<enebo>
headius: yeah ok so my question then is just can it still end up in a weird state
<enebo>
if you rollback while another thread using that connection is actively inserting will it still roll that back?
dave_____ has joined #jruby
<enebo>
Or perhaps it checks after the operation and nukes it if rollback was requested before it finished
<enebo>
Thread.current.status == 'aborting'
<enebo>
heh man a string
<headius>
yeah :-\ guess we missed that in various pushes for symbols
<enebo>
headius: ok so it seems like aborting seems like the right thing to specify it you actively request to kill
<headius>
I have no idea about any of what you're asking
<headius>
out of scope
<headius>
larger AR questions I can't even begin to guess :-)
<enebo>
headius: but my head hurts thinking about what that actually means since the thread could continue to be in abort status for a year
<headius>
I know this particular logic checks current thread's status, so it's going to be the actual end of the transaction thread
<enebo>
headius: in that case what does AR rollback_transaction mean :)
<enebo>
headius: in any case it won't commit_transaction
<enebo>
headius: so that feels like an improvement for this particular code
<headius>
if you had a thread doing a transaction while other threads are attempting to use the connection, you're already dead
<enebo>
headius: haha yeah so that is also an confusing point
<headius>
there's still known issues, like we tend to lose the aborting status if you continue to do stuff on that thread (like IO), but these are grey areas in specs and tests
<headius>
we can make an effort on related specs and tests after 9.1.14 and keep this minimal
<enebo>
headius: unless this thread is sharing the same connection or there is some magical ensure/finalization on thread death
dave_____ has quit [Ping timeout: 250 seconds]
<headius>
I'll go forward with it and see what specs we have
<headius>
down to 2F on sqlite3 for me then
<enebo>
headius: yeah I was way focused on AR for that exchange but I think generally it seems reasonable
<headius>
ok
<enebo>
headius: I just wonder why this status exists
<enebo>
headius: I guess to flag you tried
<enebo>
headius: but then why not just set a variable or something ... convenience perhaps?
<enebo>
headius: or maybe so two threads don't try and kill it if it is already aborting
<enebo>
headius: I am just spamming you to think about how we might break .14
<headius>
yeah aborting is weird because it doesn't map to anything in java thread
<headius>
a thread in Java is either not started, running, terminated, or various blocking states
<headius>
Ruby adds aborting as a sort of alternate run state
<headius>
hmm
<enebo>
headius: so only risk I can think of is someone wrote around not having this intermediate status in somethihng JRuby-specific
<headius>
maybe that's how I should be representing it...once thread is killed, set abort flag and then run status means aborting
<headius>
then there's only run status and run+abort=true so all current code is ok
<headius>
yeah I think that's unlikely
<headius>
kill is a mess anyway
<enebo>
or perhaps the opposite...something depends on this but we set it too soon or not at same important point as MRI
<enebo>
AR is one datapoint though
subbu|lunch is now known as subbu
<rdubya>
is there a preferred way to convert a hex string of arbitrary length to a binary string in java? I need it to get the bit string stuff working because apparently you can pass in "FF" and with prepared statements off it gets turned into X'FF' but with prepared statements on we need to convert it to an actual binary string (unless there is another way of flagging to postgres that a prepared statement argument is in hex)
<rdubya>
Integer.toBinaryString only supports 32 bit numbers and drops leading 0s
<rdubya>
since its only 22 possible values (accounting for lower/upper casing), was thinking about using a map so each character could be turned into a string of 8 1/0s and using a string buffer to build it up
<enebo>
rdubya: Integer.parseInt("FF", 16) and cast to char
<enebo>
build up whole string doing that perhaps using StringBuffer
<enebo>
rdubya: I don't know about something that does it en masse
<rdubya>
ok
<enebo>
rdubya: hmm I guess if it is 2 digit you can cast to a byte
<enebo>
rdubya: actually definitely don't use char :)
<enebo>
it is binary after all and limited to 256 values
<enebo>
then use byte[] which I guess is strlen/2 of original hex string
<rdubya>
I still need it to be a string of 1/0s unless postgres will take a byte array for a bit column…
<enebo>
oh
<enebo>
setBytes might work
dave____ has joined #jruby
dave____ has quit [Ping timeout: 268 seconds]
<rdubya>
looks like it needs to be a string
shellac_ has quit [Ping timeout: 250 seconds]
dave____ has joined #jruby
<enebo>
rdubya: {0 => '0', ..., F => '10000'}
<enebo>
simple 16 element primitive array 0-15
<enebo>
err you kjow what I meant
dave____ has quit [Ping timeout: 260 seconds]
<rdubya>
i'll have to duplicate a couple of them because there isn't a guarantee of it being all caps unfortunately
<rdubya>
guess i could force it to change case before the lookup, but probably easier just to handle both
<enebo>
rdubya: you could also maybe parseInt(char, 16) but I guess 32 entry array is pretty simple :)
<enebo>
rdubya: parseInt has advantage of being able to be a primitive array too
<enebo>
since you will get an indexable value back from parseInt
<rdubya>
good point
<rdubya>
another option I found Character.digit(char, 16) any pros/cons to that over parseInt ?
dave____ has joined #jruby
olle has quit [Quit: olle]
dave____ has quit [Ping timeout: 240 seconds]
<enebo>
rdubya: yeah that seems probably better since it is char and not String
<enebo>
or maybe the same if there is a char overload