On Fri, Jan 30, 2015 at 10:40 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote:
snip
Also, have you been able to validate your testing strategy for
either/both
of these POCs? Can you generate seg faults and/or valgrind warnings
On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote:
snip
Also, have you been able to validate your testing strategy for either/both
of these POCs? Can you generate seg faults and/or valgrind warnings when
you intentionally comment out the line of code that keeps the reference
On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote:
On the face of it this sounds like it could be quite brittle and probably
more complicated than just forgetting about swig for the one pn_rubyref_t
On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote:
On the face of it this sounds like it could be quite brittle and probably
more complicated than just forgetting about swig for the one pn_rubyref_t
struct and wrapping it manually. Did you attempt the latter option at all?
Yes,
On Tue, Jan 27, 2015 at 5:35 PM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Fri, Jan 23, 2015 at 03:46:34PM -0500, Darryl L. Pierce wrote:
+1 Though, I was hoping we could avoid having to manually do things...
So I have a working POC that assigns a Ruby object to a C struct in such
a way
On Wed, Jan 28, 2015 at 09:19:29AM -0500, Rafael Schloming wrote:
On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote:
On the face of it this sounds like it could be quite brittle and probably
more
On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote:
Why did you reject it then?
Are you referring to this?
Though, I was hoping we could avoid having to manually do things...
What I meant was that I would like to keep the work within the confines
of the Swig code.
--
Darryl L.
On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote:
Why did you reject it then?
Reject it? I don't recall rejecting any option.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
On Wed, Jan 28, 2015 at 1:05 PM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote:
Why did you reject it then?
Reject it? I don't recall rejecting any option.
I meant why did you post about the global array thing and not this. Is
Why did you reject it then?
--Rafael
On Wed, Jan 28, 2015 at 9:54 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at 09:19:29AM -0500, Rafael Schloming wrote:
On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Wed, Jan 28, 2015 at
On Fri, Jan 23, 2015 at 03:46:34PM -0500, Darryl L. Pierce wrote:
+1 Though, I was hoping we could avoid having to manually do things...
So I have a working POC that assigns a Ruby object to a C struct in such
a way as to keep the Ruby object from being reaped. The solution (for
now) stores the
On Fri, Jan 23, 2015 at 11:02:59AM -0500, Rafael Schloming wrote:
snip
For more info on how to integrate with Ruby's GC you can read this
article[1]. It's one of the few pieces of documentation I've found that
actually explain how to keep a reference from C to a Ruby object.
[1]
It does talk about what swig does, but it also talks about the other
direction:
If the C structure references other ruby objects, then the mark function
pointer must also be provided and must properly mark the other objects with
rb_gc_mark()
--Rafael
On Fri, Jan 23, 2015 at 1:24 PM, Darryl L.
On Fri, Jan 23, 2015 at 2:08 PM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Fri, Jan 23, 2015 at 01:49:34PM -0500, Rafael Schloming wrote:
It does talk about what swig does, but it also talks about the other
direction:
If the C structure references other ruby objects, then the mark
On Fri, Jan 23, 2015 at 01:49:34PM -0500, Rafael Schloming wrote:
It does talk about what swig does, but it also talks about the other
direction:
If the C structure references other ruby objects, then the mark function
pointer must also be provided and must properly mark the other objects
On Fri, Jan 23, 2015 at 03:25:33PM -0500, Rafael Schloming wrote:
On Fri, Jan 23, 2015 at 2:08 PM, Darryl L. Pierce dpie...@redhat.com
wrote:
On Fri, Jan 23, 2015 at 01:49:34PM -0500, Rafael Schloming wrote:
It does talk about what swig does, but it also talks about the other
That sounds like progress, but from what you're describing I'm not sure
you're actually testing C holding onto a reference to Ruby. As you say,
swig is helping you out with the Ruby - C direction, but we need to be
able to make that void * reference actually point to a ruby object (that is
not
17 matches
Mail list logo
