Here it is, at last. Bright, shiny. I think I'm going to cry.
SQLite3/Ruby 1.0.0 is ready for public consumption. This release
doesn't really change very much from the 0.9 release:
* /usr/local installations of sqlite3 are now detected by default.
* Various BSDs are now supported by the DL version of the driver.
* Bind parameters are flattened before use, allowing both of the
following syntaxes:
db.execute( "...", 1, 2, 3 )
db.execute( "...", [1, 2, 3] )
A few very minor bugs have been fixed as well.
The most exciting part of this release (to me) is the
brand-spanking-new user manual:
http://docs.jamisbuck.org/read/book/3
Many, many thanks to Tobias Luetke for the excellent Hieraki software!
- Jamis
···
--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."
Great timing,
today I worked on a SQLite2 backend for Og 
Perhaps I can switch to SQLite3 now.
Thanks for the release.
George.
Jamis Buck wrote:
SQLite3/Ruby 1.0.0 is ready for public consumption.
The error message is little oblique,
$ sudo gem install sqlite3
Attempting local installation of 'sqlite3'
Local gem file not found: sqlite3*.gem
Attempting remote installation of 'sqlite3'
Updating Gem source index for: http://gems.rubyforge.org
Select which gem to install for your platform (i686-linux)
1. sqlite3-ruby 1.0.0 (ruby)
2. sqlite3-ruby 1.0.0 (mswin32)
3. sqlite3-ruby 0.9.0 (ruby)
4. sqlite3-ruby 0.9.0 (mswin32)
5. sqlite3-ruby 0.6.0 (ruby)
6. sqlite3-ruby 0.5.0 (ruby)
7. Cancel installation
> 1
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in /usr/local/pkgs/ruby-1.8.2/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.0.0 for inspection.
ruby extconf.rb install sqlite3\nchecking for sqlite3.h... no
Results logged to /usr/local/pkgs/ruby-1.8.2/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.0.0/ext/sqlite3_api/gem_make.out
but even this bonehead can figure out that
I need to install SQLite3 first...
Regards,
···
--
Bil Kleb, Hampton, Virginia
I'll be very interested in your experience writing an Og backend for
SQLite3. Please let me know how it goes!
- Jamis
···
On 06:05 Sun 06 Feb , George Moschovitis wrote:
Great timing,
today I worked on a SQLite2 backend for Og 
Perhaps I can switch to SQLite3 now.
Thanks for the release.
George.
--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."
Bil Kleb said:
The error message is little oblique,
$ sudo gem install sqlite3
[snip]
Gem files will remain installed in
/usr/local/pkgs/ruby-1.8.2/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.0.0
for inspection.
ruby extconf.rb install sqlite3\nchecking for sqlite3.h... no
I had to do a
$ sudo gem install sqlite3 -- \
--with-sqlite3-include=/usr/local/include \
--with-sqlite3-lib=/usr/local/lib
It's funny, because the extconf.rb has
dir_config( "sqlite3", "/usr/local", "/usr/local" )
When installing it from the source, changing it to
dir_config( "sqlite3", "/usr/local/include", "/usr/local/lib" )
made it work, but I always thought the just passing the prefix to mkmf
would be enough.
Andre
I'll be very interested in your experience writing an Og backend for
SQLite3. Please let me know how it goes!
I had some problems yesterday with SQLite2 (some strange table locks).
I 'll try again with v3 today, and contact you by email if I have a
question.
regards,
George
I'll be very interested in your experience writing an Og backend for
SQLite3. Please let me know how it goes!
I had some problems yesterday with SQLite2 (some strange table locks).
I 'll try again with v3 today, and contact you by email if I have a
question.
regards,
George
Andre Nathan wrote:
I had to do a
$ sudo gem install sqlite3 -- \
--with-sqlite3-include=/usr/local/include \
--with-sqlite3-lib=/usr/local/lib
No such trouble here. After I saw ~64 of of ~2500 tests fail
during,
tar zxf sqlite-3.0.8.tar.gz
cd sqlite-3.0.8
configure; make; make test; make install
I blindly forged ahead and my gem install went
off without a hitch[1] -- both 1.0.0 and 1.0.1.
Later,
···
--
Bil Kleb, Hampton, Virginia
^1^ That is, except for those darned RDoc dynamic
string warnings:
lib/sqlite3/database.rb:613:65: Skipping require of dynamic string: "sqlite3/driver/#{driver.to_s.downcase}/driver"
lib/sqlite3/database.rb:618:59: Skipping require of dynamic string: "sqlite3/driver/#{d.downcase}/driver"
*grumble*
I could have *sworn* that I had that working. But I can duplicate what
you are reporting, so...
Anyway...
<rant about mkmf.rb elided to protect innocent eyes />
Sorry. I'm definitely not at my best today--we're all sick over here,
and didn't get much sleep at all last night.
I'll do some more tinkering and release a 1.0.1 that fixes this.
- Jamis
···
On 02:32 Mon 07 Feb , Andre Nathan wrote:
Bil Kleb said:
> The error message is little oblique,
>
> $ sudo gem install sqlite3
[snip]
> Gem files will remain installed in
> /usr/local/pkgs/ruby-1.8.2/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.0.0
> for inspection.
> ruby extconf.rb install sqlite3\nchecking for sqlite3.h... no
>
I had to do a
$ sudo gem install sqlite3 -- \
--with-sqlite3-include=/usr/local/include \
--with-sqlite3-lib=/usr/local/lib
It's funny, because the extconf.rb has
dir_config( "sqlite3", "/usr/local", "/usr/local" )
When installing it from the source, changing it to
dir_config( "sqlite3", "/usr/local/include", "/usr/local/lib" )
made it work, but I always thought the just passing the prefix to mkmf
would be enough.
Andre
--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."
Jamis Buck said:
I'll do some more tinkering and release a 1.0.1 that fixes this.
Cool, thanks.
I noticed this when I started a rails tutorial that uses SQLite3:
irb(main):001:0> require "sqlite3"
=> true
irb(main):002:0> db = SQLite3::Database.open( "foo.db" )
=> #<SQLite3::Database:0x824b854 @closed=false,
@handle=#<DL::PtrData:0x0x8363940 ptr=0x0x8350800 size=0 free=0x0x0>,
@translator=nil, @statement_factory=SQLite3::Statement,
@type_translation=false, @results_as_hash=false,
@driver=#<SQLite3::Driver::DL::Driver:0x81e0a90>>
irb(main):003:0> db2 = SQLite3::Database.open("bar.db")
NameError: uninitialized constant SQLite3::Driver::Native
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:619:in
`const_get'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:619:in
`load_driver'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:616:in
`each'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:616:in
`load_driver'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:107:in
`initialize'
from (irb):3:in `open'
from (irb):3
In the second Database.open, it tries to use the native driver,
although it used DL on the first one. If I force it to use DL, no
error happens.
Do you know what could be causing that? I'm using ruby 1.8.2 on
DragonFly here.
Andre
Jamis Buck said:
> I'll do some more tinkering and release a 1.0.1 that fixes this.
Cool, thanks.
I noticed this when I started a rails tutorial that uses SQLite3:
irb(main):001:0> require "sqlite3"
=> true
irb(main):002:0> db = SQLite3::Database.open( "foo.db" )
=> #<SQLite3::Database:0x824b854 @closed=false,
@handle=#<DL::PtrData:0x0x8363940 ptr=0x0x8350800 size=0 free=0x0x0>,
@translator=nil, @statement_factory=SQLite3::Statement,
@type_translation=false, @results_as_hash=false,
@driver=#<SQLite3::Driver::DL::Driver:0x81e0a90>>
irb(main):003:0> db2 = SQLite3::Database.open("bar.db")
NameError: uninitialized constant SQLite3::Driver::Native
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:619:in
`const_get'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:619:in
`load_driver'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:616:in
`each'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:616:in
`load_driver'
from
usr/local/lib/ruby/site_ruby/1.8/sqlite3/database.rb:107:in
`initialize'
from (irb):3:in `open'
from (irb):3
In the second Database.open, it tries to use the native driver,
although it used DL on the first one. If I force it to use DL, no
error happens.
Do you know what could be causing that? I'm using ruby 1.8.2 on
DragonFly here.
Yup, I think I know why this happens. I'm currently in the middle of
packing and releasing Net::SSH 1.0, but when I'm done with that I'll
work on fixing this error.
In the meantime, though, the workaround is as you
described--explicitly specify the DL driver.
Thanks for the report,
Jamis
···
On 08:04 Mon 07 Feb , Andre Nathan wrote:
Andre
--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."
Jamis Buck said:
Yup, I think I know why this happens. I'm currently in the middle of
packing and releasing Net::SSH 1.0, but when I'm done with that I'll
work on fixing this error.
Great, thanks!
In the meantime, though, the workaround is as you
described--explicitly specify the DL driver.
Yeah, I'm doing that. In fact a trivial patch to rails allows me to
specify a driver option for sqlite3 in databases.yml.
Andre