00:03 <lopex> headius: are there any tests against grapheme clusters failing ?

00:03 <lopex> skimming through name2ctype.h

00:04 <lopex> headius: also, I guess we dont need gperf they use

12:33 <rdubya> Is there a way to check if an IRubyObject is an instance of a certain Ruby class? I have it working using `callMethod` to call `is_a?` but wondered if there was a cleaner way to do it. Here's a gist with an example: https://gist.github.com/rdubya/3dfabdc73605a0e693a97a8f2d1ca8d9

12:47 <rdubya> just found the isInstance method on RubyModule, is that the best way to do it? Updated the gist

13:29 <GitHub85> [jruby] RobertFischer opened issue #4732: Error executing `elm-install` from `elm_install` gem https://git.io/v7uwG

13:58 <kares> rdubya: if its a user class than isIntance otherwise for core classes you could a `obj instanceof RubyArray`

14:36 <rdubya> kares: cool thanks

14:39 <enebo> rdubya: you can also safely use TypeConverter methods if you want it to be the actual type as well or die trying (e.g. many will raise TypeError if it is not what you expect it to be). Although that is usually for check + optional coercion + actual casting

14:41 <rdubya> enenbo: thanks for the info, I'll keep that in mind for those situations. In this case I'm just checking to see if it is that type so I think the isInstance is probably the right way to go

14:42 <rdubya> actually, since you are both here, the reason I'm doing this is to update the prepared statement binding to work with activerecord's newer way of passing in Attribute objects instead of the columns

14:43 <rdubya> it looks like it currently supports passing in different formats of bind parameters, do you think we need to keep that around?

14:43 <enebo> rdubya: as an extension of what kares says you really only want isInstance if something is extending an Array if it is expected to be a literal Array than obj instanceof RubyArray is much cheaper

14:44 <enebo> oh heh...sorry it is OID::Array

14:44 <rdubya> I need to keep a reference to the Attribute object because for some instances we'll want the original value (in the case of a postgres array) where others we'll want the typecasted value

14:44 <rdubya> enebo: yeah lol

14:46 <enebo> rdubya: you mean our Java code accepts multiple types of binding right?

14:46 <rdubya> currently it's converting the array to the string representation and when we call "connection.createArrayOf" it errors out because it is expecting an array instead of a string

14:46 <rdubya> multiple formats for the binding array

14:47 <enebo> rdubya: honestly I recall sqlite only using a single form from Rails but I do not remember if Rails is only capable of one format now

14:47 <enebo> rdubya: but we do not plan on pre-5 support at all so if Rails only has one format then we do not need multiple formats

14:48 <enebo> rdubya: although it may cause additional breakage on other adapters but at this point I assume all other adapters are broken and sqlite did not overlap javawise with postgresql at all from what I could see

14:48 <rdubya> enebo: sounds good, I'll verify that there is only one way that it comes in

14:49 <rdubya> enebo: yeah, i think all the adapters other than SQLite break if you turn on prepared statements

14:49 <enebo> rdubya: another idea I was discussing with kares the other day was to make annotations for each adapter type and marking up the java methods in the core class which was used by which adapter

14:49 <rdubya> enebo: unfortunately, activerecords new statement caching implementation only seems to work if prepared statements are enabled and there are tests that assume it is on :(

14:49 <enebo> rdubya: yeah I guess I ran into that with sqlite

14:50 <enebo> we could run many local tests but rails itself was totally borked

14:51 <enebo> The annotation idea was more around knowing if changing the java method would affect other adapters since enough impl is in Ruby and we have no easy way to trace which adapters use what

14:51 <enebo> It has the downside that it requires keeping the annos up to date...but documenting things are like that

14:52 <rdubya> that makes sense, I was also wondering about moving more of the adapter specific stuff to the adapter specific java classes

14:52 <enebo> rdubya: ah yeah you hit on something else kares and I chatted about

14:53 <enebo> rdubya: originally a goal of ar-jdbc was to sort of just work if you specified jdbc as the adapter name

14:53 <enebo> rdubya: so this generic support jammed a bunch of stuff to the common class

14:54 <enebo> rdubya: we decided this generic support is not worth supporting so if only one adapter uses a method I say put it into the specific class for that adapter

14:55 <enebo> My main disappointment when I went through sqlite was how different the postgresql adapter was (on AR side).

14:55 <rdubya> enebo: cool, is the goal going forward to make it so that ar-jdbc releases line up with rails releases? So for example ar-jdbc 2.0 is compatible with ActiveRecord 5.0 (or whatever versioning scheme makes sense)?

14:56 <enebo> rdubya: that is my personal hope but I am not sure if I have concensus or not

14:56 <rdubya> yeah seems like every adapter has some big differences in it

14:57 <enebo> It means having multiple branches for releases but if it is only for security patching maybe just cp'ing those across a few release branches is not a big maintenance concern

14:57 <enebo> At this point for sure we can eliminate pre-5 and push out something which works for current Rails 5 and then maybe have a better idea in how realistic that is

14:58 <enebo> I personally would say each Rails release is a new branch on ar-jdbc and we only ever go back for security or a massive plea that a bug needs a release

14:58 <rdubya> yeah it seems like that would help clean up the code quite a bit and allow us to target specific test suites to run against for each branch

14:59 <enebo> rdubya: then we just follow what rails does on those branches sans any internal mess ups we make

14:59 <rdubya> part of my struggle at the beginning when trying to get into it was figuring out how the tests were run and what tests should even be running since there were so many conditional things

15:00 <enebo> I guess the other part of this would be a one button release process since it might mean rolling out a number of releases

15:00 <enebo> rdubya: oh yeah I was wondering did you use that rake task I added?

15:00 <enebo> jrake rails:test:sqlite3:base_test

15:00 <enebo> I guess for you it would be rails:test:postgresl:base_test

15:01 <enebo> it only runs that one main AR test in a parallel checked out Rails

15:01 <rdubya> enebo: I've been running rake postgres_test for local tests and rake rails:test:postgres RAILS=~/repos/rails for the activerecord tests

15:02 <enebo> ah ok yeah that is the same set of tasks

15:02 <enebo> you are beyond just running the base one at this point no doubt

15:02 <rdubya> enebo: it's been a bit of a pain though because for some reason if I try to use pry when running the activerecord suite, it locks up my terminal

15:02 <enebo> rdubya: hmm

15:02 <rdubya> enebo: when running the ar-jdbc tests it works fine

15:03 <enebo> weird maybe ctrl-\ to dump java stacks

15:03 <rdubya> i have to ctrl-c the process but the terminal stops responding to keyboard input after that and i have to restart the terminal

15:04 <rdubya> i'll give that a shot

15:05 <rdubya> what tools do you usually use to debug the java code in the adapter? I've been resorting to debugMessage or throwing exceptions since I wasn't sure how to get a debugger at that level, at least not when running through the rake tasks

15:11 <enebo> rdubya: I generally do just use puts/println but with idea/intellij or netbeans you can attach to a process and step through

15:12 <enebo> ah crud I see no directions on our wiki for this

15:12 <enebo> https://github.com/jruby/jruby/wiki/DevelopingWithIntelliJ

15:13 <enebo> This shows how you can do debugging of JRuby itself as an application but this is complicated when you use stuff which respawns new runtimes

15:16 <rdubya> ok, at least I wasn't missing something obvious :) thanks for the reference I'll take a look at that

15:28 <enebo> rdubya: in the debug windows there is usually a wait for a port option

15:29 <enebo> rdubya: I do not remember the mojo on the command-line but you can set up a debug port on any java process and then you just need to have a break point set that gets hit once the connection is made

15:31 <rdubya> enebo: cool, that would definitely speed things up if I can get it working

15:32 <enebo> rdubya: when I go this route and cannot get it to start from where I want I usually just throw a gets somewhere early

15:32 <enebo> then it connects while blocked there and I hit return to move on

15:39 <rdubya> enebo: cool, thanks for all the info

15:39 <enebo> rdubya: thanks for working on this stuff too! :)

18:49 <GitHub2> [jruby] headius pushed 5 new commits to ruby-2.4: https://git.io/v7z8e

18:49 <GitHub2> jruby/ruby-2.4 ba2c11b Charles Oliver Nutter: Fix passing fd => fd options to spawn and friends....

18:49 <GitHub2> jruby/ruby-2.4 0fcea87 Charles Oliver Nutter: Tag StringIO specs we won't try to fix now....

18:49 <GitHub2> jruby/ruby-2.4 d5e67cb Charles Oliver Nutter: Guard against too-large offsets here....