2017-07-13 21:34 GMT+02:00 Eric Wong :
> +Cc: Philip and Jonathan since they encountered this three years
> ago, but we never heard back from them:
>
> https://bogomips.org/unicorn-public/?q=T_NODE+d:..20170713
>
>
> Pere Joan Martorell wrote:
>> > /home/deployer/.rbenv/versions/2.4.1/lib
Pere Joan Martorell wrote:
> I suspect that the conflicting gem was 'sequel_pg' (sequel_pg
> overwrites the inner loop of the Sequel postgres adapter row fetching
> code with a C version. The C version is significantly faster than the
> pure ruby version that Sequel uses by default), but given I d
On 07/14 09:16, Eric Wong wrote:
> Pere Joan Martorell wrote:
> > I suspect that the conflicting gem was 'sequel_pg' (sequel_pg
> > overwrites the inner loop of the Sequel postgres adapter row fetching
> > code with a C version. The C version is significantly faster than the
> > pure ruby version
ually testing the code is important, everything else
I've written here is theory ;)
(*) Fwiw, I am not fluent in reading asm for systems I run Ruby on,
but I know how clever compilers can be, and have written
about it some on ruby-core:
https://public-inbox.org/ruby-core/?q=RB
On 07/15 12:15, Eric Wong wrote:
> Jeremy Evans wrote:
> > Thanks for this patch. I'm not an RB_GC_GUARD expert, but the changes
> > look fine to me. The existing RB_GC_GUARD calls were added by me in
> > 2012 to fix an earlier segfault.[1] This is the first reported
> > RB_GC_GUARD-related segfa
Jeremy Evans wrote:
> All of Sequel's postgres adapter tests still pass with this, so I merged
> this into the master branch. I'll do some more testing of my apps, but
> unless I run into problems I plan to release this as sequel_pg 1.7.1
> early next week.
Thanks for the update. Btw, did you g
