Subject: [sup-talk] xapian-full and ncursesw gems

From: Rich Lane <[email-masked]>
Date: Mon, 28 Dec 2009 18:12:54 -0500

I've pushed two useful gems to gemcutter.

xapian-full: This is based on the existing xapian gem, but compiles
xapian-core as well as the bindings so it isn't dependent on the version
of the system xapian. It's also a newer development version that
includes the Chert backend.

ncursesw: This is a version of the ncurses gem modified to link against
the ncursesw library so you get wide character support. It also includes
the ruby 1.9.1 compile fixes.

When we switch the default index to Xapian, for ease of installation I
think we should add xapian-full as a gem dependency even though it may
be redundant with a system xapian install. The only thing I worry about
here is users lacking the full toolchain required to build Xapian.

One potential problem with the ncursesw gem is that I've kept
source compatibility with the old ncurses gem by not renaming the
files/module. This means they interact badly if both are installed. We
could change the Sup source to use new ncursesw names, but that's
annoying and breaks people doing "git pull". Thoughts?
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Tue, 29 Dec 2009 15:00:52 -0800

> includes the Chert backend.

Awesome!

> ncursesw: This is a version of the ncurses gem modified to link
> against the ncursesw library so you get wide character support. It
> also includes the ruby 1.9.1 compile fixes.

Awesome!

Thanks for doing this. This will bring us singificantly closer to
solving two of the most common problems (my ferret index crashed / my
non-ASCII chars look funny) out of the box.

> be redundant with a system xapian install. The only thing I worry
> about here is users lacking the full toolchain required to build
> Xapian.

I'm fine with this, especially if the Chert backend is significantly
better.

> One potential problem with the ncursesw gem is that I've kept source
> compatibility with the old ncurses gem by not renaming the

I think keeping source compatibility is a good idea. The conflict only
happens if both gems are loaded, so Sup can require 'ncursesw', and then
fall back to 'ncurses'.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Rich Lane <[email-masked]>
Date: Tue, 29 Dec 2009 18:58:05 -0500

> happens if both gems are loaded, so Sup can require 'ncursesw', and then

AFAIK rubygems (at least in 1.9.1) works by adding (one version of) all
installed gems to the load path. Since I didn't rename any of the
ncurses gem files/directories "require 'ncursesw'" won't work - the main
file in lib/ is still ncurses.rb. Renaming the files seems like the
most logical thing to do so I'll push an update to the gem and send in a
Sup patch to try ncursesw first.
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Tue, 29 Dec 2009 16:06:25 -0800

Reformatted excerpts from Rich Lane's message of 2009-12-29:
> Renaming the files seems like the most logical thing to do so I'll
> push an update to the gem and send in a Sup patch to try ncursesw
> first.

Agreed. Sounds great. Thanks!
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Tero Tilus <[email-masked]>
Date: Wed, 30 Dec 2009 01:17:59 +0200

Rich Lane, 2009-12-29 01:12:
> against the ncursesw library so you get wide character support.

Rich rocks!  \o/

> The only thing I worry about here is users lacking the full
> toolchain required to build Xapian.

Doesn't sound bad to me.  How tough a requirement "full toolchain
required to build Xapian" really is?  What platforms would be
problematic?

> I've kept source compatibility with the old ncurses gem by not
> renaming the files/module. This means they interact badly if both
> are installed. Thoughts?

If you say "don't you dare to require both ncurses and ncursesw" in
README and make ncursesw complain if ncurses is already required I'd
say it's as good a gem-citizen as it gets.  Then just (as William
already said) make sup try ncursesw first and fall back to ncurses if
it fails.

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk