Many thanks for the quick response Jeremy. You are right of course, as BasicObject really is basic & of course doesn't include the :class method! I'll take this up with the memory_profile gem maintainers.
Bruce On Wednesday, 24 August 2016 15:25:50 UTC+1, Jeremy Evans wrote: > > On Wednesday, August 24, 2016 at 6:50:58 AM UTC-7, Bruce Steedman wrote: >> >> First off, I'm a huge fan of Sequel, big thanks to JE for maintaining >> such a fabulous library. >> >> So, I am trying to profile memory use in my Padrino app, using the >> derailed_benchmarks <https://github.com/schneems/derailed_benchmarks> >> gem. This in turn uses the memory_profiler >> <https://github.com/SamSaffron/memory_profiler> gem for some commands. >> >> Static memory allocation profiling works fine, but when I try to profile >> objects >> created at Require time >> <https://github.com/schneems/derailed_benchmarks#objects-created-at-require-time> >> I >> get an error like this from this line >> <https://github.com/SamSaffron/memory_profiler/blob/master/lib/memory_profiler/helpers.rb#L28> >> : >> >> undefined method `name' for #<Sequel::SQL::Identifier @value=>:class> >> (NoMethodError) >> >> At first I thought I must have named a database table or row 'class', but >> I haven't. Upon investigation it appears to be the result of calling the >> :class method on an instance of Sequel::SQL::VirtualRow. Calling puts on >> the same object yields: >> >> `puts': can't convert Sequel::SQL::VirtualRow to Array >> (Sequel::SQL::VirtualRow#to_ary gives Sequel::SQL::Identifier) (TypeError) >> >> I see from the docs >> <http://sequel.jeremyevans.net/rdoc/classes/Sequel/SQL/VirtualRow.html> that >> these objects do indeed have most methods stripped - hence the unexpected >> behaviour calling :class on it. So my questions are: >> >> 1. Am I doing something wrong to have these rather hazardous objects >> instantiated in my app? >> 2. Can I prevent them from being created - or at least exposed in >> this way? >> 3. If answer is 'no' to 2., can the :class method be retained in >> these objects? >> >> If 2. and 3. draw a blank I'll have to suggest a patch to the maintainer >> of memory_profiler to prevent reliance on an object's :class method. >> >> *Using* >> Ruby 2.3.1 >> Sequel 4.32 >> derailed_benchmarks 1.3.1 >> memory_profiler 0.9.6 >> >> Any help much appreciated. >> >> Bruce >> > > I'm not sure how derailed_benchmarks/memory_profiler works. If it is > calling arbitrary methods defined in Object/Kernel on all newly created > objects, well, it's gonna have a bad time with anything subclassing from > BasicObject and not Object. > > 1) You aren't doing anything wrong (I'm guessing, you didn't post your > code or a backtrace) > 2) No, virtual row use is normal in Sequel. I'm not sure how/if Sequel is > "exposing" the objects. > 3) You'd have to add a BasicObject#class (or Sequel::BasicObject#class) > method, and I'm not sure how to write such a method without a C extension, > fiddle, FFI, or including Kernel. > > This is probably a bug/limitation/design issue with > derailed_benchmarks/memory_profiler, and you should discuss the issue with > the maintainers of those gems. If they think the problem is > Sequel-specific and not related to BasicObject subclass instances in > general, please ask them to be specific as to the cause. > > Thanks, > Jeremy > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
