[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Ruby/DL

From: Jamis Buck <jamis_buck@...>
Date: 2005-01-03 17:53:49 UTC
List: ruby-core #4076
I recently used Ruby/DL to create bindings to the SQLite3 embedded
database engine. In doing so, I found that the Ruby/DL library is not
quite up to the task. _why encouraged me to post to ruby-core to see
if these issues might be resolvable.

1) There is no way to support 64-bit integer return values with
   Ruby/DL. Without that support, the SQLite3 bindings are unusable by
   any library that needs to get the id of the last inserted row (like
   ActiveRecord).

2) Hard-coded limit to the number of callbacks. SQLite3 alone uses
   five or six callbacks. If SQLite3 were to be used in conjunction
   with other libraries that _also_ used callbacks, there could be
   problems. (I know that the number of callbacks can be specified
   when Ruby/DL is built, but the default of 10--which most people
   will be using--is small enough to be potentially problematic.
   Upping that to 20 or 30 as the default would help, but it would be
   nice to find a way to do away with the hard-coded limit
   altogether.)

3) "const char*" as a return value is handled "correctly" (which is to
   say, the return value is never freed by Ruby). Any other "const"
   pointer return type ("const void*", "const int*", etc.) is not
   handled the same way--the caller must explicitly remove the "free"
   handler from the pointer to prevent Ruby from freeing the pointer
   when it is garbage collected. It would be nice if this case were
   handled more consistently--either always requiring the explicit
   removal of the free handler from const pointer return types, or
   always performing that task for the caller.

I also encountered frequent deadlocks and segfaults when using my
SQLite3 bindings with WEBrick. I admit that this could have been my
fault, due to some bug in my own code, but I've never had this happen
except for when I used by Ruby/DL-based bindings.

Can anything be done to "fix" Ruby/DL to handle the above situations?
I tried hacking the 64-bit integer support into it, but the code was
not well documented and it appeared the changes would have to be made
in multiple places. I frankly got lost trying to find my way around.
:(

Help! :)

Thanks,

Jamis

-- 
Jamis Buck
jamis_buck@byu.edu
http://www.jamisbuck.org/jamis
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."


In This Thread

Prev Next