[PATCH 0/8] packaging: fedora: general updates
Hi, It doesn't seem the spec file is properly maintained, it should be much better now, closer to Fedora's one, and with support for Ruby bindings. Felipe Contreras (8): packaging: fedora: update packaging: fedora: remove irrelevant stuff packaging: fedora: trivial cleanups packaging: fedora: reorganize files section packaging: fedora: separate package for emacs packaging: fedora: package python bindings packaging: fedora: package notmuch-mutt packaging: fedora: add ruby bindings packaging/fedora/notmuch.spec | 195 -- 1 file changed, 111 insertions(+), 84 deletions(-) -- 1.8.2.1.1031.g2ee5873 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Tue, Apr 23, 2013 at 6:35 PM, David Bremner wrote: > On the other hand, there is some time to clean things up since I won't > upload new packages to Debian before the next notmuch release. And I do > consider uploading a package to Debian to be an extra personal > responsibility, especially when it is part of notmuch that I am not > maintaining. I understand that you are not going to work on the Debian packages for some time, but what prevents this patch from being merged to notmuch 'master'? Is there any problems with the patch? Shall I just push it? -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Tue, Apr 23, 2013 at 6:35 PM, David Bremner wrote: > On the other hand, there is some time to clean things up since I won't > upload new packages to Debian before the next notmuch release. And I do > consider uploading a package to Debian to be an extra personal > responsibility, especially when it is part of notmuch that I am not > maintaining. I understand that you are not going to work on the Debian packages for some time, but what prevents this patch from being merged to notmuch 'master'? Is there any problems with the patch? Shall I just push it? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Tue, Apr 23, 2013 at 6:35 PM, David Bremner wrote: > Felipe Contreras writes: > >> On Mon, Apr 15, 2013 at 5:34 AM, David Bremner wrote: >>> >>> OK, but that doesn't really help us deal with support requests e.g. on IRC. >>> Some "feature requests" for the bindings: >> >> Can you point to some of these requests, or are they hypothetical? > > I don't know how many support requests we've got, but yes, I remember at > least one. That's not a huge motivation. >> Moreover, wouldn't making sure that the bindings are package mostly >> solve this issue? > > Well, people wouldn't have to build and install the bindings, _if_ they > happened to be using an OS with packages available. But not everyone > uses binary packages. I guess for me it's just a software quality issue > to have some minimal level of documentation. If somebody needs that information it's very easy find, just googling 'notmuch ruby bindings', or looking at the way packages do it, which this patch actually helps to solve. -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Tue, Apr 23, 2013 at 6:35 PM, David Bremner wrote: > Felipe Contreras writes: > >> On Mon, Apr 15, 2013 at 5:34 AM, David Bremner wrote: >>> >>> OK, but that doesn't really help us deal with support requests e.g. on IRC. >>> Some "feature requests" for the bindings: >> >> Can you point to some of these requests, or are they hypothetical? > > I don't know how many support requests we've got, but yes, I remember at > least one. That's not a huge motivation. >> Moreover, wouldn't making sure that the bindings are package mostly >> solve this issue? > > Well, people wouldn't have to build and install the bindings, _if_ they > happened to be using an OS with packages available. But not everyone > uses binary packages. I guess for me it's just a software quality issue > to have some minimal level of documentation. If somebody needs that information it's very easy find, just googling 'notmuch ruby bindings', or looking at the way packages do it, which this patch actually helps to solve. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] debian: package ruby bindings
Signed-off-by: Felipe Contreras
---
debian/control | 14 ++
debian/notmuch-ruby.install | 1 +
debian/rules| 3 +++
3 files changed, 18 insertions(+)
create mode 100644 debian/notmuch-ruby.install
diff --git a/debian/control b/debian/control
index 854a32a..c59d3ea 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
libz-dev,
python-all (>= 2.6.6-3~),
python3-all (>= 3.1.2-7~),
+ ruby, ruby-dev,
emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) |
emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
gdb,
@@ -89,6 +90,19 @@ Description: Python 3 interface to the notmuch mail search
and index library
This package provides a Python 3 interface to the notmuch
functionality, directly interfacing with a shared notmuch library.
+Package: notmuch-ruby
+Architecture: any
+Section: ruby
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Ruby interface to the notmuch mail search and index library
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages in maildir or mh format. It uses
+ the Xapian library to provide fast, full-text search with a very
+ convenient search syntax.
+ .
+ This package provides a Ruby interface to the notmuch
+ functionality, directly interfacing with a shared notmuch library.
+
Package: notmuch-emacs
Architecture: all
Section: mail
diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install
new file mode 100644
index 000..98e7050
--- /dev/null
+++ b/debian/notmuch-ruby.install
@@ -0,0 +1 @@
+usr/lib/ruby/vendor_ruby/*/*/notmuch.so
diff --git a/debian/rules b/debian/rules
index c4e3930..71a5602 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,15 +12,18 @@ override_dh_auto_build:
dh_auto_build
dh_auto_build --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py build
+ cd bindings/ruby && ruby extconf.rb --vendor && make
$(MAKE) -C contrib/notmuch-mutt
override_dh_auto_clean:
dh_auto_clean
dh_auto_clean --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py clean -a
+ dh_auto_clean --sourcedirectory bindings/ruby
$(MAKE) -C contrib/notmuch-mutt clean
override_dh_auto_install:
dh_auto_install
dh_auto_install --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py install
--install-layout=deb --root=$(CURDIR)/debian/tmp
+ dh_auto_install --sourcedirectory bindings/ruby
--
1.8.2.1.679.g509521a
[PATCH] debian: package ruby bindings
On Mon, Apr 15, 2013 at 5:24 AM, David Bremner wrote: > Felipe Contreras writes: >>> The package is still installing files into /usr/local, which is a >>> violation of debian policy 9.1.2 >>> >>> It's a good idea to run "lintian" on the resulting debian packages; >>> that's how I caught the problem with /usr/local. >> >> Tell that to debian maintainers who configure ruby that way: > > [ ruby config deleted ] > > I don't know if there is a bug in the Debian ruby package or not, but > that does not change whether our package is allowed to install into > /usr/local. I suspect the argument is that those defaults are sensible > for admins installing ruby packages on their own systems without using > the debian package system. I asked the debian ruby packages and looked everywhere, but there was no guidance at all. Nonetheless I think this does the trick: --- a/debian/notmuch-ruby.install +++ b/debian/notmuch-ruby.install @@ -1 +1 @@ -usr/local/lib/site_ruby/*/*/notmuch.so +usr/lib/ruby/vendor_ruby/*/*/notmuch.so diff --git a/debian/rules b/debian/rules index 1dd59d2..fed680b 100755 --- a/debian/rules +++ b/debian/rules @@ -12,7 +12,7 @@ override_dh_auto_build: dh_auto_build dh_auto_build --sourcedirectory bindings/python cd bindings/python && $(python3_all) setup.py build - cd bindings/ruby && ruby extconf.rb && make + cd bindings/ruby && ruby extconf.rb --vendor && make $(MAKE) -C contrib/notmuch-mutt override_dh_auto_clean: Cheers. -- Felipe Contreras
[PATCH v2] debian: package ruby bindings
Signed-off-by: Felipe Contreras
---
debian/control | 14 ++
debian/notmuch-ruby.install | 1 +
debian/rules| 3 +++
3 files changed, 18 insertions(+)
create mode 100644 debian/notmuch-ruby.install
diff --git a/debian/control b/debian/control
index 854a32a..c59d3ea 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
libz-dev,
python-all (>= 2.6.6-3~),
python3-all (>= 3.1.2-7~),
+ ruby, ruby-dev,
emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) |
emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
gdb,
@@ -89,6 +90,19 @@ Description: Python 3 interface to the notmuch mail search
and index library
This package provides a Python 3 interface to the notmuch
functionality, directly interfacing with a shared notmuch library.
+Package: notmuch-ruby
+Architecture: any
+Section: ruby
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Ruby interface to the notmuch mail search and index library
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages in maildir or mh format. It uses
+ the Xapian library to provide fast, full-text search with a very
+ convenient search syntax.
+ .
+ This package provides a Ruby interface to the notmuch
+ functionality, directly interfacing with a shared notmuch library.
+
Package: notmuch-emacs
Architecture: all
Section: mail
diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install
new file mode 100644
index 000..98e7050
--- /dev/null
+++ b/debian/notmuch-ruby.install
@@ -0,0 +1 @@
+usr/lib/ruby/vendor_ruby/*/*/notmuch.so
diff --git a/debian/rules b/debian/rules
index c4e3930..71a5602 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,15 +12,18 @@ override_dh_auto_build:
dh_auto_build
dh_auto_build --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py build
+ cd bindings/ruby && ruby extconf.rb --vendor && make
$(MAKE) -C contrib/notmuch-mutt
override_dh_auto_clean:
dh_auto_clean
dh_auto_clean --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py clean -a
+ dh_auto_clean --sourcedirectory bindings/ruby
$(MAKE) -C contrib/notmuch-mutt clean
override_dh_auto_install:
dh_auto_install
dh_auto_install --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py install
--install-layout=deb --root=$(CURDIR)/debian/tmp
+ dh_auto_install --sourcedirectory bindings/ruby
--
1.8.2.1.679.g509521a
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] debian: package ruby bindings
On Mon, Apr 15, 2013 at 5:24 AM, David Bremner wrote: > Felipe Contreras writes: >>> The package is still installing files into /usr/local, which is a >>> violation of debian policy 9.1.2 >>> >>> It's a good idea to run "lintian" on the resulting debian packages; >>> that's how I caught the problem with /usr/local. >> >> Tell that to debian maintainers who configure ruby that way: > > [ ruby config deleted ] > > I don't know if there is a bug in the Debian ruby package or not, but > that does not change whether our package is allowed to install into > /usr/local. I suspect the argument is that those defaults are sensible > for admins installing ruby packages on their own systems without using > the debian package system. I asked the debian ruby packages and looked everywhere, but there was no guidance at all. Nonetheless I think this does the trick: --- a/debian/notmuch-ruby.install +++ b/debian/notmuch-ruby.install @@ -1 +1 @@ -usr/local/lib/site_ruby/*/*/notmuch.so +usr/lib/ruby/vendor_ruby/*/*/notmuch.so diff --git a/debian/rules b/debian/rules index 1dd59d2..fed680b 100755 --- a/debian/rules +++ b/debian/rules @@ -12,7 +12,7 @@ override_dh_auto_build: dh_auto_build dh_auto_build --sourcedirectory bindings/python cd bindings/python && $(python3_all) setup.py build - cd bindings/ruby && ruby extconf.rb && make + cd bindings/ruby && ruby extconf.rb --vendor && make $(MAKE) -C contrib/notmuch-mutt override_dh_auto_clean: Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Mon, Apr 15, 2013 at 5:34 AM, David Bremner wrote: > Felipe Contreras writes: > > >>> On a related note, is the ruby build >>> procedure documented somewhere? >> >> Not really, it's just standard. >> > > OK, but that doesn't really help us deal with support requests e.g. on IRC. > Some "feature requests" for the bindings: Can you point to some of these requests, or are they hypothetical? Moreover, wouldn't making sure that the bindings are package mostly solve this issue? > 1. Add a short README describing how to build, and how to read the docs > (it looks like there is a public) > > 2. Add a couple tests at least reaching the (low) bar set by the python >bindings > > 3. Build and install the docs locally as part of the (in-progress) > debian package That would be good, but it's out of scope for this patch. -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Mon, Apr 15, 2013 at 5:34 AM, David Bremner wrote: > Felipe Contreras writes: > > >>> On a related note, is the ruby build >>> procedure documented somewhere? >> >> Not really, it's just standard. >> > > OK, but that doesn't really help us deal with support requests e.g. on IRC. > Some "feature requests" for the bindings: Can you point to some of these requests, or are they hypothetical? Moreover, wouldn't making sure that the bindings are package mostly solve this issue? > 1. Add a short README describing how to build, and how to read the docs > (it looks like there is a public) > > 2. Add a couple tests at least reaching the (low) bar set by the python >bindings > > 3. Build and install the docs locally as part of the (in-progress) > debian package That would be good, but it's out of scope for this patch. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Sun, Apr 14, 2013 at 8:52 AM, David Bremner wrote: > Felipe Contreras writes: > >> >> diff --git a/debian/control b/debian/control >> index 854a32a..620c5ce 100644 >> --- a/debian/control >> +++ b/debian/control >> @@ -15,6 +15,7 @@ Build-Depends: >> libz-dev, >> python-all (>= 2.6.6-3~), >> python3-all (>= 3.1.2-7~), >> + ruby-dev, >> emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) | >> emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~), >> gdb, > > This doesn't build in a clean sid chroot, because ruby-dev does not > depend on ruby, so you need to explicitly add it. Right, I just found that too. >> Package: notmuch-emacs >> Architecture: all >> Section: mail >> diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install >> new file mode 100644 >> index 000..f92f09c >> --- /dev/null >> +++ b/debian/notmuch-ruby.install >> @@ -0,0 +1 @@ >> +usr/local/lib/site_ruby/*/*/notmuch.so >> diff --git a/debian/rules b/debian/rules >> index c4e3930..7c7247a 100755 >> --- a/debian/rules >> +++ b/debian/rules >> @@ -12,15 +12,24 @@ override_dh_auto_build: >> dh_auto_build >> dh_auto_build --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py build >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && ruby extconf.rb && make > > Why are both these lines needed? The first one isn't. > On a related note, is the ruby build > procedure documented somewhere? Not really, it's just standard. >> override_dh_auto_clean: >> dh_auto_clean >> dh_auto_clean --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py clean -a >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && test -f Makefile && make clean || true >> $(MAKE) -C contrib/notmuch-mutt clean > > This looks suspect, calling dh_auto_build from the clean target. A mistake, probably the first line is enough. > The > clean target cannot assume that e.g. notmuch is already built. It doesn't, that's what the 'test -f Makefile' was for. >> override_dh_auto_install: >> dh_auto_install >> dh_auto_install --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py install >> --install-layout=deb --root=$(CURDIR)/debian/tmp >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && make install DESTDIR=$(CURDIR)/debian/tmp > > This call to dh_auto_build also confuses me. The top level sequencer > will ensure that the override_dh_auto_build is called before this one. A mistake. >> + >> +# ruby's site is configured in /usr/local >> +override_dh_usrlocal: > > The package is still installing files into /usr/local, which is a > violation of debian policy 9.1.2 > > It's a good idea to run "lintian" on the resulting debian packages; > that's how I caught the problem with /usr/local. Tell that to debian maintainers who configure ruby that way: require 'rbconfig' RbConfig::CONFIG['sitelibdir'] => "/usr/local/lib/site_ruby/1.9.1" RbConfig::CONFIG['configure_args'] => " '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/ruby1.9.1' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-pthread' '--enable-shared' '--disable-rpath' '--disable-install-doc' '--with-vendordir=/usr/lib/ruby/vendor_ruby' '--with-sitedir=/usr/local/lib/site_ruby' '--program-suffix=1.9.1' '--with-soname=ruby-1.9.1' '--with-baseruby=/usr/bin/ruby1.8' '--enable-ipv6' '--with-dbm-type=gdbm_compat' '--with-tklib=tk8.5' '--with-tcllib=tcl8.5' '--with-tcl-include=/usr/include/tcl8.5' '--with-bundled-sha1' '--with-bundled-md5' '--with-bundled-rmd160' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -fno-strict-aliasing' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=
Re: [PATCH] debian: package ruby bindings
On Sun, Apr 14, 2013 at 8:52 AM, David Bremner wrote: > Felipe Contreras writes: > >> >> diff --git a/debian/control b/debian/control >> index 854a32a..620c5ce 100644 >> --- a/debian/control >> +++ b/debian/control >> @@ -15,6 +15,7 @@ Build-Depends: >> libz-dev, >> python-all (>= 2.6.6-3~), >> python3-all (>= 3.1.2-7~), >> + ruby-dev, >> emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) | >> emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~), >> gdb, > > This doesn't build in a clean sid chroot, because ruby-dev does not > depend on ruby, so you need to explicitly add it. Right, I just found that too. >> Package: notmuch-emacs >> Architecture: all >> Section: mail >> diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install >> new file mode 100644 >> index 000..f92f09c >> --- /dev/null >> +++ b/debian/notmuch-ruby.install >> @@ -0,0 +1 @@ >> +usr/local/lib/site_ruby/*/*/notmuch.so >> diff --git a/debian/rules b/debian/rules >> index c4e3930..7c7247a 100755 >> --- a/debian/rules >> +++ b/debian/rules >> @@ -12,15 +12,24 @@ override_dh_auto_build: >> dh_auto_build >> dh_auto_build --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py build >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && ruby extconf.rb && make > > Why are both these lines needed? The first one isn't. > On a related note, is the ruby build > procedure documented somewhere? Not really, it's just standard. >> override_dh_auto_clean: >> dh_auto_clean >> dh_auto_clean --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py clean -a >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && test -f Makefile && make clean || true >> $(MAKE) -C contrib/notmuch-mutt clean > > This looks suspect, calling dh_auto_build from the clean target. A mistake, probably the first line is enough. > The > clean target cannot assume that e.g. notmuch is already built. It doesn't, that's what the 'test -f Makefile' was for. >> override_dh_auto_install: >> dh_auto_install >> dh_auto_install --sourcedirectory bindings/python >> cd bindings/python && $(python3_all) setup.py install >> --install-layout=deb --root=$(CURDIR)/debian/tmp >> + dh_auto_build --sourcedirectory bindings/ruby >> + cd bindings/ruby && make install DESTDIR=$(CURDIR)/debian/tmp > > This call to dh_auto_build also confuses me. The top level sequencer > will ensure that the override_dh_auto_build is called before this one. A mistake. >> + >> +# ruby's site is configured in /usr/local >> +override_dh_usrlocal: > > The package is still installing files into /usr/local, which is a > violation of debian policy 9.1.2 > > It's a good idea to run "lintian" on the resulting debian packages; > that's how I caught the problem with /usr/local. Tell that to debian maintainers who configure ruby that way: require 'rbconfig' RbConfig::CONFIG['sitelibdir'] => "/usr/local/lib/site_ruby/1.9.1" RbConfig::CONFIG['configure_args'] => " '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib/ruby1.9.1' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--enable-pthread' '--enable-shared' '--disable-rpath' '--disable-install-doc' '--with-vendordir=/usr/lib/ruby/vendor_ruby' '--with-sitedir=/usr/local/lib/site_ruby' '--program-suffix=1.9.1' '--with-soname=ruby-1.9.1' '--with-baseruby=/usr/bin/ruby1.8' '--enable-ipv6' '--with-dbm-type=gdbm_compat' '--with-tklib=tk8.5' '--with-tcllib=tcl8.5' '--with-tcl-include=/usr/include/tcl8.5' '--with-bundled-sha1' '--with-bundled-md5' '--with-bundled-rmd160' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -fno-strict-aliasing' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=
[PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 10:00 AM, David Bremner wrote: > Probably you should test in unstable (sid) since that's where the > official packages get built. It's also a newer version of python3 (and > hence dh_python3). I'll give that a try. > The current packages are multi-arch, so they actually install into > /usr/lib/$(arch_triple)/libnotmuch.so; I'm not sure if that is a typo on > your part, or something is wrong there as well. Not according to debian: http://packages.debian.org/sid/amd64/libnotmuch-dev/filelist -- Felipe Contreras
[PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 6:35 AM, David Bremner wrote: > Felipe Contreras writes: > Mainly I've been busy. I need to double check the ruby packaging with > somebody else. So, please continue to be patient, and not modify the > stuff in ./debian. All right. I installed debian squeeze through debootstrap to test this, and everything worked fine except for dh_python3 renaming .so files, but that happened also for /usr/lib/libnotmuch.so, which makes me think that dh_python3 is all buggy and nobody is really using it at this point. Cheers. -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 10:00 AM, David Bremner wrote: > Probably you should test in unstable (sid) since that's where the > official packages get built. It's also a newer version of python3 (and > hence dh_python3). I'll give that a try. > The current packages are multi-arch, so they actually install into > /usr/lib/$(arch_triple)/libnotmuch.so; I'm not sure if that is a typo on > your part, or something is wrong there as well. Not according to debian: http://packages.debian.org/sid/amd64/libnotmuch-dev/filelist -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 6:35 AM, David Bremner wrote: > Felipe Contreras writes: > Mainly I've been busy. I need to double check the ruby packaging with > somebody else. So, please continue to be patient, and not modify the > stuff in ./debian. All right. I installed debian squeeze through debootstrap to test this, and everything worked fine except for dh_python3 renaming .so files, but that happened also for /usr/lib/libnotmuch.so, which makes me think that dh_python3 is all buggy and nobody is really using it at this point. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 1:14 AM, Tomi Ollila wrote: > On Sat, Apr 13 2013, Felipe Contreras wrote: > >> On Wed, Apr 3, 2013 at 5:27 PM, Felipe Contreras >> wrote: >>> Signed-off-by: Felipe Contreras >>> --- >>> debian/control | 14 ++ >>> debian/notmuch-ruby.install | 1 + >>> debian/rules| 9 + >>> 3 files changed, 24 insertions(+) >>> create mode 100644 debian/notmuch-ruby.install >> >> No comments? Should I push this? > > How do we ensure that ruby package is working in every release; > there seems to be no tests for it ? We probably should have tests, but how is that relevant to this patch? The code is already there, and distributions are already shipping it: https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/notmuch If there's reason to be worried about shipping something that doesn't work, too late, we are already shipping it. And that's orthogonal to this patch, shouldn't prevent it to be merged. Cheers. -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Sat, Apr 13, 2013 at 1:14 AM, Tomi Ollila wrote: > On Sat, Apr 13 2013, Felipe Contreras wrote: > >> On Wed, Apr 3, 2013 at 5:27 PM, Felipe Contreras >> wrote: >>> Signed-off-by: Felipe Contreras >>> --- >>> debian/control | 14 ++ >>> debian/notmuch-ruby.install | 1 + >>> debian/rules| 9 + >>> 3 files changed, 24 insertions(+) >>> create mode 100644 debian/notmuch-ruby.install >> >> No comments? Should I push this? > > How do we ensure that ruby package is working in every release; > there seems to be no tests for it ? We probably should have tests, but how is that relevant to this patch? The code is already there, and distributions are already shipping it: https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/notmuch If there's reason to be worried about shipping something that doesn't work, too late, we are already shipping it. And that's orthogonal to this patch, shouldn't prevent it to be merged. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
On Wed, Apr 3, 2013 at 5:27 PM, Felipe Contreras wrote: > Signed-off-by: Felipe Contreras > --- > debian/control | 14 ++ > debian/notmuch-ruby.install | 1 + > debian/rules| 9 + > 3 files changed, 24 insertions(+) > create mode 100644 debian/notmuch-ruby.install No comments? Should I push this? -- Felipe Contreras
Re: [PATCH] debian: package ruby bindings
On Wed, Apr 3, 2013 at 5:27 PM, Felipe Contreras wrote: > Signed-off-by: Felipe Contreras > --- > debian/control | 14 ++ > debian/notmuch-ruby.install | 1 + > debian/rules| 9 + > 3 files changed, 24 insertions(+) > create mode 100644 debian/notmuch-ruby.install No comments? Should I push this? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] notmuch-vim-ruby v0.5
Hi, After a long period of inactivity, here is the new version of notmuch-vim-ruby. The main changes are: * New fallback mode when mail gem is not available * Simplified build and setup * More features: arbitrary tags, save messages * Saner defaults So the chances it will work properly right away are much higher now. And for the people using Arch Linux: https://aur.archlinux.org/packages/vim-notmuch/ Grab it from the usual location: https://github.com/felipec/notmuch-vim-ruby Cheers. Felipe Contreras (9): Add option to save a message Update documentation Add simple mail parser Copy notmuch-vim syntax build: add Makefile build: add target to compile the ruby bindings Update README with simpler instructions No need for full sendmail path Improve build instructions Kirill A. Shutemov (5): README: fix typo open_reply: fallback to use addr.local if addr.name is nil Use /usr/sbin/sendmail as a default Introduce g:notmuch_rb_folders_count_threads show_reply: set compose_done appropriately Kit Westneat (3): Add support for arbitrary tags. Assume + if tag does not start with + or - refresh search results after adding a tag -- Felipe Contreras
the future of notmuch-vim?
On Wed, Apr 3, 2013 at 3:48 PM, Patrick Totzke wrote: > Quoting Felipe Contreras (2013-04-03 10:09:39) >> ... >> What you prefer is irrelevant; it's relevant only for you, that's why it's >> called a *preference*, the rest of us prefer different things. > > Never mind preferences, I think originally, this thread was about dropping > *support* for the *original* vim plugin that lives in notmuch/contrib. > I think we can all agree that this is reasonable. The reasons for dropping the original vim script are exactly the same reasons why it should be replaced with the ruby version. > This should not keep you from hacking on your script, hosting > it whereever you like and support it. > For me, one of the charms of notmuch is exactly this extensibility. Bpth are "my" scripts. I'm supposed to be the maintainer of the vim script and I have commit access. -- Felipe Contreras
[PATCH] debian: package ruby bindings
Signed-off-by: Felipe Contreras
---
debian/control | 14 ++
debian/notmuch-ruby.install | 1 +
debian/rules| 9 +
3 files changed, 24 insertions(+)
create mode 100644 debian/notmuch-ruby.install
diff --git a/debian/control b/debian/control
index 854a32a..620c5ce 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
libz-dev,
python-all (>= 2.6.6-3~),
python3-all (>= 3.1.2-7~),
+ ruby-dev,
emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) |
emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
gdb,
@@ -89,6 +90,19 @@ Description: Python 3 interface to the notmuch mail search
and index library
This package provides a Python 3 interface to the notmuch
functionality, directly interfacing with a shared notmuch library.
+Package: notmuch-ruby
+Architecture: any
+Section: ruby
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Ruby interface to the notmuch mail search and index library
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages in maildir or mh format. It uses
+ the Xapian library to provide fast, full-text search with a very
+ convenient search syntax.
+ .
+ This package provides a Ruby interface to the notmuch
+ functionality, directly interfacing with a shared notmuch library.
+
Package: notmuch-emacs
Architecture: all
Section: mail
diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install
new file mode 100644
index 000..f92f09c
--- /dev/null
+++ b/debian/notmuch-ruby.install
@@ -0,0 +1 @@
+usr/local/lib/site_ruby/*/*/notmuch.so
diff --git a/debian/rules b/debian/rules
index c4e3930..7c7247a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,15 +12,24 @@ override_dh_auto_build:
dh_auto_build
dh_auto_build --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py build
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && ruby extconf.rb && make
$(MAKE) -C contrib/notmuch-mutt
override_dh_auto_clean:
dh_auto_clean
dh_auto_clean --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py clean -a
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && test -f Makefile && make clean || true
$(MAKE) -C contrib/notmuch-mutt clean
override_dh_auto_install:
dh_auto_install
dh_auto_install --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py install
--install-layout=deb --root=$(CURDIR)/debian/tmp
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && make install DESTDIR=$(CURDIR)/debian/tmp
+
+# ruby's site is configured in /usr/local
+override_dh_usrlocal:
--
1.8.2
[ANN] notmuch-vim-ruby v0.5
Hi, After a long period of inactivity, here is the new version of notmuch-vim-ruby. The main changes are: * New fallback mode when mail gem is not available * Simplified build and setup * More features: arbitrary tags, save messages * Saner defaults So the chances it will work properly right away are much higher now. And for the people using Arch Linux: https://aur.archlinux.org/packages/vim-notmuch/ Grab it from the usual location: https://github.com/felipec/notmuch-vim-ruby Cheers. Felipe Contreras (9): Add option to save a message Update documentation Add simple mail parser Copy notmuch-vim syntax build: add Makefile build: add target to compile the ruby bindings Update README with simpler instructions No need for full sendmail path Improve build instructions Kirill A. Shutemov (5): README: fix typo open_reply: fallback to use addr.local if addr.name is nil Use /usr/sbin/sendmail as a default Introduce g:notmuch_rb_folders_count_threads show_reply: set compose_done appropriately Kit Westneat (3): Add support for arbitrary tags. Assume + if tag does not start with + or - refresh search results after adding a tag -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: the future of notmuch-vim?
On Wed, Apr 3, 2013 at 3:48 PM, Patrick Totzke wrote: > Quoting Felipe Contreras (2013-04-03 10:09:39) >> ... >> What you prefer is irrelevant; it's relevant only for you, that's why it's >> called a *preference*, the rest of us prefer different things. > > Never mind preferences, I think originally, this thread was about dropping > *support* for the *original* vim plugin that lives in notmuch/contrib. > I think we can all agree that this is reasonable. The reasons for dropping the original vim script are exactly the same reasons why it should be replaced with the ruby version. > This should not keep you from hacking on your script, hosting > it whereever you like and support it. > For me, one of the charms of notmuch is exactly this extensibility. Bpth are "my" scripts. I'm supposed to be the maintainer of the vim script and I have commit access. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] debian: package ruby bindings
Signed-off-by: Felipe Contreras
---
debian/control | 14 ++
debian/notmuch-ruby.install | 1 +
debian/rules| 9 +
3 files changed, 24 insertions(+)
create mode 100644 debian/notmuch-ruby.install
diff --git a/debian/control b/debian/control
index 854a32a..620c5ce 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
libz-dev,
python-all (>= 2.6.6-3~),
python3-all (>= 3.1.2-7~),
+ ruby-dev,
emacs23-nox | emacs23 (>=23~) | emacs23-lucid (>=23~) |
emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~),
gdb,
@@ -89,6 +90,19 @@ Description: Python 3 interface to the notmuch mail search
and index library
This package provides a Python 3 interface to the notmuch
functionality, directly interfacing with a shared notmuch library.
+Package: notmuch-ruby
+Architecture: any
+Section: ruby
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Ruby interface to the notmuch mail search and index library
+ Notmuch is a system for indexing, searching, reading, and tagging
+ large collections of email messages in maildir or mh format. It uses
+ the Xapian library to provide fast, full-text search with a very
+ convenient search syntax.
+ .
+ This package provides a Ruby interface to the notmuch
+ functionality, directly interfacing with a shared notmuch library.
+
Package: notmuch-emacs
Architecture: all
Section: mail
diff --git a/debian/notmuch-ruby.install b/debian/notmuch-ruby.install
new file mode 100644
index 000..f92f09c
--- /dev/null
+++ b/debian/notmuch-ruby.install
@@ -0,0 +1 @@
+usr/local/lib/site_ruby/*/*/notmuch.so
diff --git a/debian/rules b/debian/rules
index c4e3930..7c7247a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,15 +12,24 @@ override_dh_auto_build:
dh_auto_build
dh_auto_build --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py build
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && ruby extconf.rb && make
$(MAKE) -C contrib/notmuch-mutt
override_dh_auto_clean:
dh_auto_clean
dh_auto_clean --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py clean -a
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && test -f Makefile && make clean || true
$(MAKE) -C contrib/notmuch-mutt clean
override_dh_auto_install:
dh_auto_install
dh_auto_install --sourcedirectory bindings/python
cd bindings/python && $(python3_all) setup.py install
--install-layout=deb --root=$(CURDIR)/debian/tmp
+ dh_auto_build --sourcedirectory bindings/ruby
+ cd bindings/ruby && make install DESTDIR=$(CURDIR)/debian/tmp
+
+# ruby's site is configured in /usr/local
+override_dh_usrlocal:
--
1.8.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
the future of notmuch-vim?
guyzmo wrote: > On Tue, Apr 02, 2013 at 01:55:13PM -0600, Felipe Contreras wrote: > > Sorry for the late reply, I wasn't following the ml. > > same here > > > David Bremner wrote: > > > - There are now several alternatives for people whose only motivation to > > > use the vim frontend was dislike of emacs (alot and notmuch-mutt). > > I did try the emacs frontend, and it was not working properly for me at the > > time, and I believe I documented my issues. It was not just my dislike of > > emacs > > that motivated me to write notmuch-vim-ruby. > > I'd say not liking emacs is not a good reason for using vim as a > MUA. Vim is just a text editor, and nothing else. Vim is a pretty extensible text editor that works prectly fine as a MUA, in fact, much better than any other MUA I've ever used. That is a good reason. > > > There are several alternative vim frontends floating around in (at > > > least) ruby and python. I don't if they are better or worse > > > functionality wise. > > I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) > > It may be nice and/or fun to use that kind of things in vim, but > really, it's opposite to the philosophy of vim. The philosophy of vim is irrelevant, what is relevant is what you can do with it, and you can use it as a perfectly good MUA. > I personnally prefer a thousand times to use mutt-kz, alot as MUA, and > vim only for writing mails. What you prefer is irrelevant; it's relevant only for you, that's why it's called a *preference*, the rest of us prefer different things. I've tried mutt-kz and alot, and I was utterly dissapointed by both. See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these respects. [1] http://www.youtube.com/watch?v=JGD7IbZmnIs -- Felipe Contreras
Re: the future of notmuch-vim?
guyzmo wrote: > On Tue, Apr 02, 2013 at 01:55:13PM -0600, Felipe Contreras wrote: > > Sorry for the late reply, I wasn't following the ml. > > same here > > > David Bremner wrote: > > > - There are now several alternatives for people whose only motivation to > > > use the vim frontend was dislike of emacs (alot and notmuch-mutt). > > I did try the emacs frontend, and it was not working properly for me at the > > time, and I believe I documented my issues. It was not just my dislike of > > emacs > > that motivated me to write notmuch-vim-ruby. > > I'd say not liking emacs is not a good reason for using vim as a > MUA. Vim is just a text editor, and nothing else. Vim is a pretty extensible text editor that works prectly fine as a MUA, in fact, much better than any other MUA I've ever used. That is a good reason. > > > There are several alternative vim frontends floating around in (at > > > least) ruby and python. I don't if they are better or worse > > > functionality wise. > > I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) > > It may be nice and/or fun to use that kind of things in vim, but > really, it's opposite to the philosophy of vim. The philosophy of vim is irrelevant, what is relevant is what you can do with it, and you can use it as a perfectly good MUA. > I personnally prefer a thousand times to use mutt-kz, alot as MUA, and > vim only for writing mails. What you prefer is irrelevant; it's relevant only for you, that's why it's called a *preference*, the rest of us prefer different things. I've tried mutt-kz and alot, and I was utterly dissapointed by both. See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these respects. [1] http://www.youtube.com/watch?v=JGD7IbZmnIs -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
the future of notmuch-vim?
Hi, Sorry for the late reply, I wasn't following the ml. David Bremner wrote: > There is apparently still some people that use it (although notice the > "Vote" column is 0). > > On the other hand > > - The vim frontend is afaik the last thing depending on the legacy text > output format. > > - The plugin seems to be only semi-functional at the moment; in a quick > test I found a message that didn't display it's content, and one that > displayed the content, along with "junk" from the internal > representation. Indeed, I'd say the code is very poor at best. > - There are now several alternatives for people whose only motivation to > use the vim frontend was dislike of emacs (alot and notmuch-mutt). I did try the emacs frontend, and it was not working properly for me at the time, and I believe I documented my issues. It was not just my dislike of emacs that motivated me to write notmuch-vim-ruby. > There are several alternative vim frontends floating around in (at > least) ruby and python. I don't if they are better or worse > functionality wise. I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) > I'm considering stopping building debian packages for notmuch-vim, since > I don't see any current prospects for the package improving. I'm not > sure what the equivalent thing to do upstream would be, perhaps moving > it to contrib. Or, deprecating it and then removing it. > > What do people think? Personally I think notmuch-vim should be replaced with notmuch-vim-ruby. I did try the python version, and remember discussing options with the guy developing it, but nothing happened out of it, and I think the ruby version is superior. I'd be open to discuss the options here, but I think notmuch-vim-ruby is the only real option. Cheers. -- Felipe Contreras
[PATCH 0/5] Random patches for notmuch-vim-ruby
Hi, Sorry for the late reply, I haven't really been following or doing any development, but I'm back. Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Kirill A. Shutemov (5): > open_reply: fallback to use addr.local if addr.name is nil > rename g:notmuch_sendmail -> g:notmuch_rb_sendmail > /usr/sbin/sendmail as a default g:notmuch_rb_sendmail > Introduce g:notmuch_rb_folders_count_threads > Drop harmful reply buffer preparation -- Felipe Contreras
[PATCH 5/5] Drop harmful reply buffer preparation
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Inserting empty lines at the end of reply buffer and switching to insert > mode are not what user want on reply. It's only annoying if you try to > comment on patch. > > If a user really wants this kind of preparation it should be implemented > as an user-specific hook. Insert mode, maybe, but the empty lines don't hurt. See, with your patch I end up in: > part = orig.find_first_text > part.convert.each_line do |l| > body_lines << "> %s" % l.chomp > -- > 1.7.10.4 <- HERE > > -- I cannot type there, and in any case I have to remove those lines, so I end selecting the text upwards and remove them. With the current code: > part = orig.find_first_text > part.convert.each_line do |l| > body_lines << "> %s" % l.chomp > -- > 1.7.10.4 > > <- HERE > > -- Not much of a difference, I still have to select the lines upwards and remove them. That is of course if you reply *inline*. You might want to reply to the whole thing without modifications, in which case the original behavior is more useful. I'm not strongly opposed to this, but I don't see why those extra lines would hurt. Cheers. -- Felipe Contreras
[PATCH 4/5] Introduce g:notmuch_rb_folders_count_threads
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > If the option set, folders list shows count of threads, not messages > folders.each do |name, search| > q = db.query(search) > $searches << search > - b << "%9d %-20s (%s)" % > [q.search_messages.count, name, search] > + count = count_threads == 0 ? > + q.search_messages.count : > q.search_threads.count I prefer: count = count_threads ? q.search_threads.count : q.search_messages.count But other than that looks good to me. Applied. -- Felipe Contreras
[PATCH 3/5] /usr/sbin/sendmail as a default g:notmuch_rb_sendmail
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > It's confusing that we don't have a default sendmail program. Let's use > /usr/sbin/sendmail as reasonable default. Applied. -- Felipe Contreras
[PATCH 1/5] open_reply: fallback to use addr.local if addr.name is nil
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > If address doesn't contain name we end up with " wrote:" as a reply > header. It doesn't look nice. > > Let's use addr.local + "@" if name is not defined. If addr.local is not > defined too, let's just use "somebody". Thanks. Applied. -- Felipe Contreras
[PATCH 2/5] rename g:notmuch_sendmail -> g:notmuch_rb_sendmail
On Mon, Jan 28, 2013 at 9:52 AM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > All configuration variable use prefix notmuch_rb_ except > notmuch_sendmail. Let's fix it. I'm not sure about this one. notmuch-vim is official, what happens if you have both notmuch-vim and notmuch-vim-ruby? Wouldn't it be nice to use the same variable for configuration? -- Felipe Contreras
RE: the future of notmuch-vim?
Hi, Sorry for the late reply, I wasn't following the ml. David Bremner wrote: > There is apparently still some people that use it (although notice the > "Vote" column is 0). > > On the other hand > > - The vim frontend is afaik the last thing depending on the legacy text > output format. > > - The plugin seems to be only semi-functional at the moment; in a quick > test I found a message that didn't display it's content, and one that > displayed the content, along with "junk" from the internal > representation. Indeed, I'd say the code is very poor at best. > - There are now several alternatives for people whose only motivation to > use the vim frontend was dislike of emacs (alot and notmuch-mutt). I did try the emacs frontend, and it was not working properly for me at the time, and I believe I documented my issues. It was not just my dislike of emacs that motivated me to write notmuch-vim-ruby. > There are several alternative vim frontends floating around in (at > least) ruby and python. I don't if they are better or worse > functionality wise. I'd say notmuch-vim-ruby is the best one, but of course I'm biased :) > I'm considering stopping building debian packages for notmuch-vim, since > I don't see any current prospects for the package improving. I'm not > sure what the equivalent thing to do upstream would be, perhaps moving > it to contrib. Or, deprecating it and then removing it. > > What do people think? Personally I think notmuch-vim should be replaced with notmuch-vim-ruby. I did try the python version, and remember discussing options with the guy developing it, but nothing happened out of it, and I think the ruby version is superior. I'd be open to discuss the options here, but I think notmuch-vim-ruby is the only real option. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 0/5] Random patches for notmuch-vim-ruby
Hi, Sorry for the late reply, I haven't really been following or doing any development, but I'm back. Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Kirill A. Shutemov (5): > open_reply: fallback to use addr.local if addr.name is nil > rename g:notmuch_sendmail -> g:notmuch_rb_sendmail > /usr/sbin/sendmail as a default g:notmuch_rb_sendmail > Introduce g:notmuch_rb_folders_count_threads > Drop harmful reply buffer preparation -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 5/5] Drop harmful reply buffer preparation
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > Inserting empty lines at the end of reply buffer and switching to insert > mode are not what user want on reply. It's only annoying if you try to > comment on patch. > > If a user really wants this kind of preparation it should be implemented > as an user-specific hook. Insert mode, maybe, but the empty lines don't hurt. See, with your patch I end up in: > part = orig.find_first_text > part.convert.each_line do |l| > body_lines << "> %s" % l.chomp > -- > 1.7.10.4 <- HERE > > -- I cannot type there, and in any case I have to remove those lines, so I end selecting the text upwards and remove them. With the current code: > part = orig.find_first_text > part.convert.each_line do |l| > body_lines << "> %s" % l.chomp > -- > 1.7.10.4 > > <- HERE > > -- Not much of a difference, I still have to select the lines upwards and remove them. That is of course if you reply *inline*. You might want to reply to the whole thing without modifications, in which case the original behavior is more useful. I'm not strongly opposed to this, but I don't see why those extra lines would hurt. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 4/5] Introduce g:notmuch_rb_folders_count_threads
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > If the option set, folders list shows count of threads, not messages > folders.each do |name, search| > q = db.query(search) > $searches << search > - b << "%9d %-20s (%s)" % > [q.search_messages.count, name, search] > + count = count_threads == 0 ? > + q.search_messages.count : > q.search_threads.count I prefer: count = count_threads ? q.search_threads.count : q.search_messages.count But other than that looks good to me. Applied. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 3/5] /usr/sbin/sendmail as a default g:notmuch_rb_sendmail
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > It's confusing that we don't have a default sendmail program. Let's use > /usr/sbin/sendmail as reasonable default. Applied. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH 1/5] open_reply: fallback to use addr.local if addr.name is nil
Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > If address doesn't contain name we end up with " wrote:" as a reply > header. It doesn't look nice. > > Let's use addr.local + "@" if name is not defined. If addr.local is not > defined too, let's just use "somebody". Thanks. Applied. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/5] rename g:notmuch_sendmail -> g:notmuch_rb_sendmail
On Mon, Jan 28, 2013 at 9:52 AM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > All configuration variable use prefix notmuch_rb_ except > notmuch_sendmail. Let's fix it. I'm not sure about this one. notmuch-vim is official, what happens if you have both notmuch-vim and notmuch-vim-ruby? Wouldn't it be nice to use the same variable for configuration? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
gmail label support patch available for oflineimap
On Thu, Nov 29, 2012 at 6:01 AM, Jeremy Nickurak wrote: > Doing this on a directory basis is a non-starter for me. The reason that > Notmuch and gmail are a natural fit is that they both operate on labels/tags > instead of folders. There's no simpler way if you are using IMAP and Maildir, and there are no better alternatives. -- Felipe Contreras
gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 1:53 PM, Michal Nazarewicz wrote: > On Wed, Nov 28 2012, Felipe Contreras wrote: >> Not everybody uses offlineimap. > > Go nag developers of whatever you are using to implement fetching labels > from Gmail. Or write another tool that does that. Why do that when I can do it in notmuch? > Either way, communicating with Gmail is not notmuch's job. Who said anything like that? -- Felipe Contreras
gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 12:29 PM, Jani Nikula wrote: > > On Nov 28, 2012 12:10 PM, "Felipe Contreras" > wrote: >> >> On Wed, Nov 28, 2012 at 8:32 AM, Rainer M Krug wrote: >> >> >> I just want to say that having notmuch communicate with Gmail is >> >> terrible idea, since this >> >> would mean duplicating of jobs that offlineimap and notmuch do. >> > >> > My sentiments, notmuch is doing realy good what it is doing, and adding >> > gmail / other server >> > communication is not the best idea. >> >> And I disagree. > > Which part do you disagree with, before or after "and", or both? Care to > elaborate, in either case? Any concrete suggestions? After the "and" of course :) I think it would be trivial to add Gmail-style folders to notmuch. Maybe a configuration that maps directories with tags. This in fact wouldn't even be Gmail specific, and would help the people coming from procmail, and other ways of organizing mail. Cheers. -- Felipe Contreras
Re: gmail label support patch available for oflineimap
On Thu, Nov 29, 2012 at 6:01 AM, Jeremy Nickurak wrote: > Doing this on a directory basis is a non-starter for me. The reason that > Notmuch and gmail are a natural fit is that they both operate on labels/tags > instead of folders. There's no simpler way if you are using IMAP and Maildir, and there are no better alternatives. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 1:53 PM, Michal Nazarewicz wrote: > On Wed, Nov 28 2012, Felipe Contreras wrote: >> Not everybody uses offlineimap. > > Go nag developers of whatever you are using to implement fetching labels > from Gmail. Or write another tool that does that. Why do that when I can do it in notmuch? > Either way, communicating with Gmail is not notmuch's job. Who said anything like that? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 12:29 PM, Jani Nikula wrote: > > On Nov 28, 2012 12:10 PM, "Felipe Contreras" > wrote: >> >> On Wed, Nov 28, 2012 at 8:32 AM, Rainer M Krug wrote: >> >> >> I just want to say that having notmuch communicate with Gmail is >> >> terrible idea, since this >> >> would mean duplicating of jobs that offlineimap and notmuch do. >> > >> > My sentiments, notmuch is doing realy good what it is doing, and adding >> > gmail / other server >> > communication is not the best idea. >> >> And I disagree. > > Which part do you disagree with, before or after "and", or both? Care to > elaborate, in either case? Any concrete suggestions? After the "and" of course :) I think it would be trivial to add Gmail-style folders to notmuch. Maybe a configuration that maps directories with tags. This in fact wouldn't even be Gmail specific, and would help the people coming from procmail, and other ways of organizing mail. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 8:32 AM, Rainer M Krug wrote: >> I just want to say that having notmuch communicate with Gmail is terrible >> idea, since this >> would mean duplicating of jobs that offlineimap and notmuch do. > > My sentiments, notmuch is doing realy good what it is doing, and adding gmail > / other server > communication is not the best idea. And I disagree. >> I could see some *other* tool, besides notmuch and offlineimap, which >> connects to Gmail to >> fetch the tags, but that would again duplicate a lot of the code from >> offlineimap. > > I also agree here - offlineimap already has a repository type Gmail, and if > gmails imap > extensions, particularly > https://developers.google.com/google-apps/gmail/imap_extensions#access_to_gmail_labels_x-gm-labels > is used, it should be not to difficult to read the labels and to store them > in e.g. a sqlite > database for each message id. This could then be written back as well, and > only the [GMAIL] folder > would have to be synchronised, i.e. no duplication. Not everybody uses offlineimap. -- Felipe Contreras
Re: gmail label support patch available for oflineimap
On Wed, Nov 28, 2012 at 8:32 AM, Rainer M Krug wrote: >> I just want to say that having notmuch communicate with Gmail is terrible >> idea, since this >> would mean duplicating of jobs that offlineimap and notmuch do. > > My sentiments, notmuch is doing realy good what it is doing, and adding gmail > / other server > communication is not the best idea. And I disagree. >> I could see some *other* tool, besides notmuch and offlineimap, which >> connects to Gmail to >> fetch the tags, but that would again duplicate a lot of the code from >> offlineimap. > > I also agree here - offlineimap already has a repository type Gmail, and if > gmails imap > extensions, particularly > https://developers.google.com/google-apps/gmail/imap_extensions#access_to_gmail_labels_x-gm-labels > is used, it should be not to difficult to read the labels and to store them > in e.g. a sqlite > database for each message id. This could then be written back as well, and > only the [GMAIL] folder > would have to be synchronised, i.e. no duplication. Not everybody uses offlineimap. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANNOUNCE] notmuchfs - A virtual maildir file system for notmuch queries
On Mon, Oct 1, 2012 at 2:55 AM, David Bremner wrote: > Tim Stoakes writes: > >> Hello fellow notmuch-ers, >> >> What is notmuchfs? >> -- >> Notmuchfs implements a virtual file system which creates maildirs from >> notmuch >> mail query results. This is useful for using notmuch with tools which are not >> aware of notmuch, only maildirs - such as mutt. >> >> Basically you 'mkdir' your query strings, then point your tool of choice at >> that directory, and it turns into a virtual maildir containing the query >> results. >> > > Well, since nobody else said it, let me be the first to say, that's a > pretty cool hack! I agree. Genius :) -- Felipe Contreras
Re: [ANNOUNCE] notmuchfs - A virtual maildir file system for notmuch queries
On Mon, Oct 1, 2012 at 2:55 AM, David Bremner wrote: > Tim Stoakes writes: > >> Hello fellow notmuch-ers, >> >> What is notmuchfs? >> -- >> Notmuchfs implements a virtual file system which creates maildirs from >> notmuch >> mail query results. This is useful for using notmuch with tools which are not >> aware of notmuch, only maildirs - such as mutt. >> >> Basically you 'mkdir' your query strings, then point your tool of choice at >> that directory, and it turns into a virtual maildir containing the query >> results. >> > > Well, since nobody else said it, let me be the first to say, that's a > pretty cool hack! I agree. Genius :) -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] notmuch vim ruby v0.4
On Mon, Jun 4, 2012 at 1:51 PM, Kirill A. Shutemov wrote: > On Mon, Jun 04, 2012 at 12:35:21PM +0200, Felipe Contreras wrote: >> Hi, >> >> Here's a new version of notmuch-vim-ruby, a new attempt to have a >> proper vim interface for notmuch. > > Hm. No links? Oops! I knew that message was missing something :P https://github.com/felipec/notmuch-vim-ruby -- Felipe Contreras
[ANN] notmuch vim ruby v0.4
Hi, Here's a new version of notmuch-vim-ruby, a new attempt to have a proper vim interface for notmuch. Changes since v0.3: * Avoid wiping other user key-bindings * Improved encoding of messages (some servers complained) * Automatically fetch notmuch configuration (no need for g:notmuch_rb_database) * Improved view of messages * Improved efficiency of tagging * Properly synchronize maildir falgs * Compatibility with Ruby 1.8 * New option to show next message () * New option to search from the search view itself Thanks to Chris Hoffman for some of these fixes. There is still some on the encoding of outgoing messages that I haven't managed to nail down, but I don't want to hold this release because of that. There's plenty of good stuff already, and this plugin works perfectly fine for me as it is. Cheers. -- Felipe Contreras
Re: [ANN] notmuch vim ruby v0.4
On Mon, Jun 4, 2012 at 1:51 PM, Kirill A. Shutemov wrote: > On Mon, Jun 04, 2012 at 12:35:21PM +0200, Felipe Contreras wrote: >> Hi, >> >> Here's a new version of notmuch-vim-ruby, a new attempt to have a >> proper vim interface for notmuch. > > Hm. No links? Oops! I knew that message was missing something :P https://github.com/felipec/notmuch-vim-ruby -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] notmuch vim ruby v0.4
Hi, Here's a new version of notmuch-vim-ruby, a new attempt to have a proper vim interface for notmuch. Changes since v0.3: * Avoid wiping other user key-bindings * Improved encoding of messages (some servers complained) * Automatically fetch notmuch configuration (no need for g:notmuch_rb_database) * Improved view of messages * Improved efficiency of tagging * Properly synchronize maildir falgs * Compatibility with Ruby 1.8 * New option to show next message () * New option to search from the search view itself Thanks to Chris Hoffman for some of these fixes. There is still some on the encoding of outgoing messages that I haven't managed to nail down, but I don't want to hold this release because of that. There's plenty of good stuff already, and this plugin works perfectly fine for me as it is. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 8:17 PM, David Bremner wrote: > Jameson Graef Rollins writes: > >> I don't know, but this is one of the reasons I'm against having >> "contrib" stuff in the notmuch repo. ?If it's not part of the stuff >> we're willing to release in source tarballs or binary packages then it >> should probably be in a separate repo. > > Just to be clear, ./contrib currently is in the source tarballs, and at > least notmuch-mutt is included in a binary package for debian. > > I don't disagree that status is kindof odd, but I don't see the stuff in > contrib as being that different in practice from the bindings. In both > cases we have had incidences of bitrot. The python bindings are > currently not a problem, but both the ruby and go bindings stopped > working at all recently. I see these as different issues: ruby bindings not working because of a change in the ruby bindings is understandable, but ruby bindings not working because of an API change *and* that nobody bothered to implement this change would not make sense to me. Maybe ruby maintainers don't have that much time, which is why they don't make so many changes; but the bindings still work, and if somebody has the time to make changes, well, he has the time, but forcing the issue when breaking API does not make sense. I don't see why it would be difficult to do the API updates through all the notmuch code; if we can't update the API through all the code in a timely manner, how do we hope 3rd party uses would? If anything it would be an incentive to don't break the API so often; let's face it, notmuch is not so widely used, and breaking the API is not going to help things. Another option is to go the FFmpeg way: create a new function notmuch_database_open2, mark the old one as deprecated (but still works), and only after some time obsolete it. Cheers. -- Felipe Contreras
Re: Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 8:17 PM, David Bremner wrote: > Jameson Graef Rollins writes: > >> I don't know, but this is one of the reasons I'm against having >> "contrib" stuff in the notmuch repo. If it's not part of the stuff >> we're willing to release in source tarballs or binary packages then it >> should probably be in a separate repo. > > Just to be clear, ./contrib currently is in the source tarballs, and at > least notmuch-mutt is included in a binary package for debian. > > I don't disagree that status is kindof odd, but I don't see the stuff in > contrib as being that different in practice from the bindings. In both > cases we have had incidences of bitrot. The python bindings are > currently not a problem, but both the ruby and go bindings stopped > working at all recently. I see these as different issues: ruby bindings not working because of a change in the ruby bindings is understandable, but ruby bindings not working because of an API change *and* that nobody bothered to implement this change would not make sense to me. Maybe ruby maintainers don't have that much time, which is why they don't make so many changes; but the bindings still work, and if somebody has the time to make changes, well, he has the time, but forcing the issue when breaking API does not make sense. I don't see why it would be difficult to do the API updates through all the notmuch code; if we can't update the API through all the code in a timely manner, how do we hope 3rd party uses would? If anything it would be an incentive to don't break the API so often; let's face it, notmuch is not so widely used, and breaking the API is not going to help things. Another option is to go the FFmpeg way: create a new function notmuch_database_open2, mark the old one as deprecated (but still works), and only after some time obsolete it. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 8:44 AM, Tomi Ollila wrote: > On Fri, Jun 01 2012, Jostein Gogstad wrote: >> I'm trying to compile notmuch-deliver, but after I get this error: >> >> ? CC ? ? main.o >> ? main.c: In function ?main?: >> ? main.c:432: error: too few arguments to function ?notmuch_database_open? >> ? make[2]: *** [main.o] Error 1 >> >> Any ideas? Tried with the version that ships with 0.13, and the version >> in HEAD (they seem similar though). > > Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin > or Ali may fix that some day... > > .. or Someone Else(TM)... patches welcome :D I'd say the one who breaks the API does the necessary changes in all notmuch code, otherwise what's the point of having the code in the same repo? This is how the Linux kernel does it. I would be in favor of reverting these changes, and possibly put them in a separate branch, until they are ready (as in all notmuch code compiles). Cheers. -- Felipe Contreras
Re: Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 8:44 AM, Tomi Ollila wrote: > On Fri, Jun 01 2012, Jostein Gogstad wrote: >> I'm trying to compile notmuch-deliver, but after I get this error: >> >> CC main.o >> main.c: In function ‘main’: >> main.c:432: error: too few arguments to function ‘notmuch_database_open’ >> make[2]: *** [main.o] Error 1 >> >> Any ideas? Tried with the version that ships with 0.13, and the version >> in HEAD (they seem similar though). > > Yes, commit 5fddc07d (*) changes notmuch_database_open() interface. Austin > or Ali may fix that some day... > > .. or Someone Else(TM)... patches welcome :D I'd say the one who breaks the API does the necessary changes in all notmuch code, otherwise what's the point of having the code in the same repo? This is how the Linux kernel does it. I would be in favor of reverting these changes, and possibly put them in a separate branch, until they are ready (as in all notmuch code compiles). Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Thu, May 24, 2012 at 10:56 AM, Felipe Contreras wrote: > On Thu, May 24, 2012 at 3:22 AM, David Bremner wrote: >> I do plan on a bug fix release, to fix an annoying emacs interface bug >> if nothing else. I'd rather see a fix/revert coordinated with Ali in his >> role as ruby bindings maintainer. > > Well, sure, if possible that would be best. But I doubt the ruby > bindings maintainer would complain about making the Ruby bindings work > again :) > > Worst-case scenario we would end up with what we had before. Since I've seen no better alternatives to fix the problem, I've reverted the patch and pushed to 'master'. Would be nice to pick it for 'release'. Cheers. -- Felipe Contreras
Re: [PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Thu, May 24, 2012 at 10:56 AM, Felipe Contreras wrote: > On Thu, May 24, 2012 at 3:22 AM, David Bremner wrote: >> I do plan on a bug fix release, to fix an annoying emacs interface bug >> if nothing else. I'd rather see a fix/revert coordinated with Ali in his >> role as ruby bindings maintainer. > > Well, sure, if possible that would be best. But I doubt the ruby > bindings maintainer would complain about making the Ruby bindings work > again :) > > Worst-case scenario we would end up with what we had before. Since I've seen no better alternatives to fix the problem, I've reverted the patch and pushed to 'master'. Would be nice to pick it for 'release'. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Thu, May 24, 2012 at 3:22 AM, David Bremner wrote: > Felipe Contreras writes: > > >> I don't see how this patch could be fixed properly easily, and it was >> labeled as a hack, and I didn't like it in the first place anyway, so >> I'm going to revert it by tomorrow if I don't hear any good reason not >> to. > > I think this highlights the need for at least a minimal test suite for > the ruby Yeap, I thought the same. > I do plan on a bug fix release, to fix an annoying emacs interface bug > if nothing else. I'd rather see a fix/revert coordinated with Ali in his > role as ruby bindings maintainer. Well, sure, if possible that would be best. But I doubt the ruby bindings maintainer would complain about making the Ruby bindings work again :) Worst-case scenario we would end up with what we had before. > FWIW, the previous situation of linking with the installed version of > notmuch sounds somewhat broken as well, although obviously preferable to > not working at all. That would be only if there was installed version of notmuch, which some people don't have (e.g. me). Either way, to fix that particular problem we don't need to link to the static library, we can just the right CFLAGS and LDFLAGS, in fact, I wonder how is it that it's not working properly; AFAIK the linker and compiler would use first the headers and libraries found in these flags, and only as a fallback use the system ones, so if anybody has managed to compile before (I have) the headers and libraries would be in some -I/-L path. I could try to investigate, but at the moment I still see no reason not to revert. Cheers. -- Felipe Contreras
Re: [PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Thu, May 24, 2012 at 3:22 AM, David Bremner wrote: > Felipe Contreras writes: > > >> I don't see how this patch could be fixed properly easily, and it was >> labeled as a hack, and I didn't like it in the first place anyway, so >> I'm going to revert it by tomorrow if I don't hear any good reason not >> to. > > I think this highlights the need for at least a minimal test suite for > the ruby Yeap, I thought the same. > I do plan on a bug fix release, to fix an annoying emacs interface bug > if nothing else. I'd rather see a fix/revert coordinated with Ali in his > role as ruby bindings maintainer. Well, sure, if possible that would be best. But I doubt the ruby bindings maintainer would complain about making the Ruby bindings work again :) Worst-case scenario we would end up with what we had before. > FWIW, the previous situation of linking with the installed version of > notmuch sounds somewhat broken as well, although obviously preferable to > not working at all. That would be only if there was installed version of notmuch, which some people don't have (e.g. me). Either way, to fix that particular problem we don't need to link to the static library, we can just the right CFLAGS and LDFLAGS, in fact, I wonder how is it that it's not working properly; AFAIK the linker and compiler would use first the headers and libraries found in these flags, and only as a fallback use the system ones, so if anybody has managed to compile before (I have) the headers and libraries would be in some -I/-L path. I could try to investigate, but at the moment I still see no reason not to revert. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
On Tue, May 15, 2012 at 5:15 AM, Karl Harris wrote: > I am trying the notmuch-vim-ruby plugin for the first time.? Previously, I > had been using the vim plugin that comes with notmuch. > > If I type :NotMuchR in vim, I get the following error messages: > -- > Error detected while processing function 19_NotMuchR: > line? 304: > LoadError: /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so: undefined > symbol: _ZTVN10__cxxabiv117__class_type_infoE - > /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/no > tmuch.so > Error detected while processing function > 19_NotMuchR..19_folders..19_new_buffer: > line??? 6: > NoMethodError: undefined method `push' for nil:NilClass > Error detected while processing function 19_NotMuchR..19_folders: > line??? 2: > NoMethodError: undefined method `folders_render' for main:Object > - > > Can anyone point me in the direction of where to start troubleshooting > this?? In the past, I have had issues in other ruby applications that dealt > with ruby versions.? Could this be an issue? Looks like the Ruby bindings are completely broken thanks to (82b73ff ruby: Add workarounds to use in-tree build not the installed one). Please use v0.12. Cheers. -- Felipe Contreras
[PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Mon, May 7, 2012 at 5:02 PM, Ali Polatel wrote: > - Make mkmf use the notmuch.h under ../../lib > - Use libnotmuch.a instead of linking to the installed libnotmuch.so How has this ever worked? libnotmuch.so links to many things, fortunately when linking Ruby's notmuch.so binding to libnotmuch.so.3 all those dependencies are resolved for us, but when you link to libnotmuch.a you need notmuch.so to link against all those dependencies. This is triggering cryptic errors such as: /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': foo/notmuch.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE - foo/notmuch.so (LoadError) Presumably because not even libstdc++.so is linked. I don't see how this patch could be fixed properly easily, and it was labeled as a hack, and I didn't like it in the first place anyway, so I'm going to revert it by tomorrow if I don't hear any good reason not to. I also suggest making a brown-paper-bag release 0.13.1 because 0.13 has completely unusable Ruby bindings; there's just no way to compile them and make them work. Cheers. -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Tue, May 15, 2012 at 5:15 AM, Karl Harris wrote: > I am trying the notmuch-vim-ruby plugin for the first time. Previously, I > had been using the vim plugin that comes with notmuch. > > If I type :NotMuchR in vim, I get the following error messages: > -- > Error detected while processing function 19_NotMuchR: > line 304: > LoadError: /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so: undefined > symbol: _ZTVN10__cxxabiv117__class_type_infoE - > /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/no > tmuch.so > Error detected while processing function > 19_NotMuchR..19_folders..19_new_buffer: > line 6: > NoMethodError: undefined method `push' for nil:NilClass > Error detected while processing function 19_NotMuchR..19_folders: > line 2: > NoMethodError: undefined method `folders_render' for main:Object > - > > Can anyone point me in the direction of where to start troubleshooting > this? In the past, I have had issues in other ruby applications that dealt > with ruby versions. Could this be an issue? Looks like the Ruby bindings are completely broken thanks to (82b73ff ruby: Add workarounds to use in-tree build not the installed one). Please use v0.12. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/4] ruby: Add workarounds to use in-tree build not the installed one
On Mon, May 7, 2012 at 5:02 PM, Ali Polatel wrote: > - Make mkmf use the notmuch.h under ../../lib > - Use libnotmuch.a instead of linking to the installed libnotmuch.so How has this ever worked? libnotmuch.so links to many things, fortunately when linking Ruby's notmuch.so binding to libnotmuch.so.3 all those dependencies are resolved for us, but when you link to libnotmuch.a you need notmuch.so to link against all those dependencies. This is triggering cryptic errors such as: /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': foo/notmuch.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE - foo/notmuch.so (LoadError) Presumably because not even libstdc++.so is linked. I don't see how this patch could be fixed properly easily, and it was labeled as a hack, and I didn't like it in the first place anyway, so I'm going to revert it by tomorrow if I don't hear any good reason not to. I also suggest making a brown-paper-bag release 0.13.1 because 0.13 has completely unusable Ruby bindings; there's just no way to compile them and make them work. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
On Tue, May 15, 2012 at 5:15 AM, Karl Harris wrote: > I am trying the notmuch-vim-ruby plugin for the first time.? Previously, I > had been using the vim plugin that comes with notmuch. > > If I type :NotMuchR in vim, I get the following error messages: > -- > Error detected while processing function 19_NotMuchR: > line? 304: > LoadError: /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so: undefined > symbol: _ZTVN10__cxxabiv117__class_type_infoE - > /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/no > tmuch.so > Error detected while processing function > 19_NotMuchR..19_folders..19_new_buffer: > line??? 6: > NoMethodError: undefined method `push' for nil:NilClass > Error detected while processing function 19_NotMuchR..19_folders: > line??? 2: > NoMethodError: undefined method `folders_render' for main:Object > - > > Can anyone point me in the direction of where to start troubleshooting > this?? In the past, I have had issues in other ruby applications that dealt > with ruby versions.? Could this be an issue? I'm not sure, what does 'ldd /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so' shows? Looks like some C++ stuff is missing somehow. -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Tue, May 15, 2012 at 5:15 AM, Karl Harris wrote: > I am trying the notmuch-vim-ruby plugin for the first time. Previously, I > had been using the vim plugin that comes with notmuch. > > If I type :NotMuchR in vim, I get the following error messages: > -- > Error detected while processing function 19_NotMuchR: > line 304: > LoadError: /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so: undefined > symbol: _ZTVN10__cxxabiv117__class_type_infoE - > /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/no > tmuch.so > Error detected while processing function > 19_NotMuchR..19_folders..19_new_buffer: > line 6: > NoMethodError: undefined method `push' for nil:NilClass > Error detected while processing function 19_NotMuchR..19_folders: > line 2: > NoMethodError: undefined method `folders_render' for main:Object > - > > Can anyone point me in the direction of where to start troubleshooting > this? In the past, I have had issues in other ruby applications that dealt > with ruby versions. Could this be an issue? I'm not sure, what does 'ldd /usr/lib/ruby/site_ruby/1.9.1/x86_64-linux/notmuch.so' shows? Looks like some C++ stuff is missing somehow. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
On Sun, Apr 29, 2012 at 12:52 AM, Alex Ghitza wrote: > Felipe Contreras wrote: >> > vim -c ':NotMuchR' >> > >> > all I get is an error message: >> > >> > Error detected while processing command line: >> > E492: Not an editor command: :NotMuchR >> >> I don't know if you did anything special to get the normal plug-in to >> work. Maybe you are doing 'source ~/.vim/plugin/notmuch.vim' directly >> in your .vimrc, if so, you can try to do the same with notmuch vim >> ruby. What I have is 'filetype plugin on'. > > After banging my head against the wall a bit more, I realised what > should have been obvious from the beginning: I need to have vim built > with ruby support. ?So after grabbing the vim source and > > ? ?./configure --enable-rubyinterp > > I am now happily writing this from notmuch-ruby. ?As obvious as this > should have been, do you think it deserves a short sentence at the top > of the == install == section of your README? All right, done :) -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Sun, Apr 29, 2012 at 12:52 AM, Alex Ghitza wrote: > Felipe Contreras wrote: >> > vim -c ':NotMuchR' >> > >> > all I get is an error message: >> > >> > Error detected while processing command line: >> > E492: Not an editor command: :NotMuchR >> >> I don't know if you did anything special to get the normal plug-in to >> work. Maybe you are doing 'source ~/.vim/plugin/notmuch.vim' directly >> in your .vimrc, if so, you can try to do the same with notmuch vim >> ruby. What I have is 'filetype plugin on'. > > After banging my head against the wall a bit more, I realised what > should have been obvious from the beginning: I need to have vim built > with ruby support. So after grabbing the vim source and > > ./configure --enable-rubyinterp > > I am now happily writing this from notmuch-ruby. As obvious as this > should have been, do you think it deserves a short sentence at the top > of the == install == section of your README? All right, done :) -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
vim plugin development -- GIT branch?
On Fri, May 4, 2012 at 3:02 PM, Karl Harris wrote: > Are there any GIT branches where vim plugin development is taking place? > ?After reading a few of the posts here about the ruby and python based > plugin, I thought it would be fun to try them out. ?If this development is > taking place in a GIT branch, it would be easy for me to access the code and > any updates. My Ruby version is here: https://github.com/felipec/notmuch-vim-ruby I also maintain the current vim pure version and have commit access to the main notmuch repo, but I don't recall any pending patches. I have some pending patches myself, but I haven't made them public anywhere (still cooking). So there's nothing pending to push. I haven't heard any feedback from anybody else regarding the vim/ruby/python situation, so I don't know what's going to happen next. Cheers. -- Felipe Contreras
[ANN] New awesome vim plug-in using Ruby bindings
On Wed, May 2, 2012 at 10:41 PM, Anton Khirnov wrote: > > On Mon, 23 Apr 2012 04:12:32 +0300, Felipe Contreras gmail.com> wrote: >> ?* Gradual searches; you don't have to wait for the whole search to finish, >> ? ?sort of like the 'less' command > > How did you do that? When I tried to do this in my version, I got hit by > vim not being threadsafe. I first started with Ruby fibers, but stumbled upon a bug, and then I realized I didn't actually need them; in Ruby there is an Enumerable class, which the Notmuch::Threads class includes, and one of the methods allows to get only a certain number of items, so regardless of what happens in the back, I only get a certain number of items at a time. This is particularly easy thanks to Ruby blocks, but I guess you can achieve the same in Python somehow. Each time the cursor changes I check if a certain threshold of items has been passed, and if so, get one more chunk. Cheers. -- Felipe Contreras
Re: vim plugin development -- GIT branch?
On Fri, May 4, 2012 at 3:02 PM, Karl Harris wrote: > Are there any GIT branches where vim plugin development is taking place? > After reading a few of the posts here about the ruby and python based > plugin, I thought it would be fun to try them out. If this development is > taking place in a GIT branch, it would be easy for me to access the code and > any updates. My Ruby version is here: https://github.com/felipec/notmuch-vim-ruby I also maintain the current vim pure version and have commit access to the main notmuch repo, but I don't recall any pending patches. I have some pending patches myself, but I haven't made them public anywhere (still cooking). So there's nothing pending to push. I haven't heard any feedback from anybody else regarding the vim/ruby/python situation, so I don't know what's going to happen next. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] vim plugin rewrite II
On Wed, May 2, 2012 at 10:23 PM, Anton Khirnov wrote: > sorry for the late reply, I see you already reached the same point as > me, except with ruby ;) Yay for competition. I think my plugin is a bit further. And yeah, competition is good, but also collaboration; hopefully the 3 plugins can share as much as possible. >> I was seriously considering to concentrate on this plugin instead of >> the current one, but I'm afraid every little error causes a crash, >> even when a subprocess fails (e.g. msmtp), so it's not really usable >> for me. Not to mention that it's really hard to debug, because every >> bug causes a crash, and sometimes I get random crashes with no >> information about what caused it at all. >> >> I am starting to work on a version that uses ruby, and it doesn't seem >> to have these issues, but lets see. I'm still not sure if we should >> depend on ruby/python bindings, maybe there's a way to make them >> optional. >> >> Anyway, if you find a way to improve the crash issues, let me know, so >> far it's the only real issue I see with this plug-in. > > That is weird, I'm not getting any crashes here. On any exception in the > python code it prints the backtrace and continues normally. I don't > think I've ever seen it actually crash (not counting my ultimately > unsuccessfull attempts at threading). I wonder what could cause this. Interesting. I would need to check that, but I don't have time right now =/ Cheers. -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Wed, May 2, 2012 at 10:41 PM, Anton Khirnov wrote: > > On Mon, 23 Apr 2012 04:12:32 +0300, Felipe Contreras > wrote: >> * Gradual searches; you don't have to wait for the whole search to finish, >> sort of like the 'less' command > > How did you do that? When I tried to do this in my version, I got hit by > vim not being threadsafe. I first started with Ruby fibers, but stumbled upon a bug, and then I realized I didn't actually need them; in Ruby there is an Enumerable class, which the Notmuch::Threads class includes, and one of the methods allows to get only a certain number of items, so regardless of what happens in the back, I only get a certain number of items at a time. This is particularly easy thanks to Ruby blocks, but I guess you can achieve the same in Python somehow. Each time the cursor changes I check if a certain threshold of items has been passed, and if so, get one more chunk. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] vim plugin rewrite II
On Wed, May 2, 2012 at 10:23 PM, Anton Khirnov wrote: > sorry for the late reply, I see you already reached the same point as > me, except with ruby ;) Yay for competition. I think my plugin is a bit further. And yeah, competition is good, but also collaboration; hopefully the 3 plugins can share as much as possible. >> I was seriously considering to concentrate on this plugin instead of >> the current one, but I'm afraid every little error causes a crash, >> even when a subprocess fails (e.g. msmtp), so it's not really usable >> for me. Not to mention that it's really hard to debug, because every >> bug causes a crash, and sometimes I get random crashes with no >> information about what caused it at all. >> >> I am starting to work on a version that uses ruby, and it doesn't seem >> to have these issues, but lets see. I'm still not sure if we should >> depend on ruby/python bindings, maybe there's a way to make them >> optional. >> >> Anyway, if you find a way to improve the crash issues, let me know, so >> far it's the only real issue I see with this plug-in. > > That is weird, I'm not getting any crashes here. On any exception in the > python code it prints the backtrace and continues normally. I don't > think I've ever seen it actually crash (not counting my ultimately > unsuccessfull attempts at threading). I wonder what could cause this. Interesting. I would need to check that, but I don't have time right now =/ Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
On Sat, Apr 28, 2012 at 1:40 PM, Alex Ghitza wrote: > vim -c ':NotMuchR' > > all I get is an error message: > > Error detected while processing command line: > E492: Not an editor command: :NotMuchR I don't know if you did anything special to get the normal plug-in to work. Maybe you are doing 'source ~/.vim/plugin/notmuch.vim' directly in your .vimrc, if so, you can try to do the same with notmuch vim ruby. What I have is 'filetype plugin on'. Cheers. -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Sat, Apr 28, 2012 at 1:40 PM, Alex Ghitza wrote: > vim -c ':NotMuchR' > > all I get is an error message: > > Error detected while processing command line: > E492: Not an editor command: :NotMuchR I don't know if you did anything special to get the normal plug-in to work. Maybe you are doing 'source ~/.vim/plugin/notmuch.vim' directly in your .vimrc, if so, you can try to do the same with notmuch vim ruby. What I have is 'filetype plugin on'. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
2012/4/23 Felipe Contreras : > So, since I'm a big fan of Ruby, I decided to try my luck writing a > plug-in from scratch. It took me one weekend, but I'm pretty happy > with the result. This plug-in has already essentially all the > functionality of the current one, but it's much, *much* simpler (only > 600) lines of code. > > And in addition has many more features: > > ?* Gradual searches; you don't have to wait for the whole search to finish, > ? sort of like the 'less' command > ?* Proper multi-part handling; finds out if there's text/plain, or if > ? text/html, converts it using elinks > ?* Extract all attachments > ?* Open message with mutt (or any external application that can open an mbox) > ?* More proper UTF-8 handling > ?* Configurable key mappings > ?* Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) In case anybody is interested, here's a screencast showing some of the features :) http://youtu.be/JGD7IbZmnIs Cheers. -- Felipe Contreras
Re: [ANN] New awesome vim plug-in using Ruby bindings
2012/4/23 Felipe Contreras : > So, since I'm a big fan of Ruby, I decided to try my luck writing a > plug-in from scratch. It took me one weekend, but I'm pretty happy > with the result. This plug-in has already essentially all the > functionality of the current one, but it's much, *much* simpler (only > 600) lines of code. > > And in addition has many more features: > > * Gradual searches; you don't have to wait for the whole search to finish, > sort of like the 'less' command > * Proper multi-part handling; finds out if there's text/plain, or if > text/html, converts it using elinks > * Extract all attachments > * Open message with mutt (or any external application that can open an mbox) > * More proper UTF-8 handling > * Configurable key mappings > * Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) In case anybody is interested, here's a screencast showing some of the features :) http://youtu.be/JGD7IbZmnIs Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
On Tue, Apr 24, 2012 at 4:15 AM, Austin Clements wrote: > Quoth Felipe Contreras on Apr 24 at ?3:45 am: >> On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: >> > 2012/4/24 Felipe Contreras : >> >> >> Personally I don't see why an object, like say a query would remain >> >> working correctly after the database is gone, either by calling >> >> .close() directly, or just loosing the pointer to the original object. >> >> I don't think users would expect that, or, even if they somehow found >> >> it useful, that most likely would be very seldom, and hardly worth >> >> worrying about it. >> > >> > Working correctly is not expected but wouldn't it be more appropriate >> > to throw an exception rather than dumping core or printing on standard >> > error? >> >> Sure, if that was possible. >> >> > I wonder whether we can make both work somehow. >> > Maybe by using talloc explicitly and keeping reference pointers? >> > I don't know whether it's worth bothering. >> >> Maybe, I don't see how, that's just not how C works. Maybe talloc does >> have some way to figure out if a pointer has been freed, but I doubt >> that, and I can't find it by grepping through the API. >> >> Another option would be hook into talloc's destructor so we know when >> an object is freed and taint it, but then we would be overriding >> notmuch's destructor, and there's no way around that (unless we tap >> into talloc's internal structures). A way to workaround that would be >> to modify notmuch's API so that we can specify a destructor for >> notmuch objects, but that would be tedious, and I doubt a lof people >> beside us would benefit from that. > > I believe (though I might be wrong) that bindings could simply > maintain their own talloc references to C objects returned by > libnotmuch to prevent them from being freed until the wrapper object > is garbage collected. ?This would require modifying all of the > library's _destroy functions to use talloc_find_parent_bytype and > talloc_unlink instead of simply calling talloc_free, but I don't think > this change would be particularly invasive and it certainly wouldn't > affect the library interface. That might work, but still, I don't see why this patch can't be applied. Cheers. -- Felipe Contreras
[PATCH] ruby: make sure the database is closed
On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: > 2012/4/24 Felipe Contreras : >> Personally I don't see why an object, like say a query would remain >> working correctly after the database is gone, either by calling >> .close() directly, or just loosing the pointer to the original object. >> I don't think users would expect that, or, even if they somehow found >> it useful, that most likely would be very seldom, and hardly worth >> worrying about it. > > Working correctly is not expected but wouldn't it be more appropriate > to throw an exception rather than dumping core or printing on standard error? Sure, if that was possible. > I wonder whether we can make both work somehow. > Maybe by using talloc explicitly and keeping reference pointers? > I don't know whether it's worth bothering. Maybe, I don't see how, that's just not how C works. Maybe talloc does have some way to figure out if a pointer has been freed, but I doubt that, and I can't find it by grepping through the API. Another option would be hook into talloc's destructor so we know when an object is freed and taint it, but then we would be overriding notmuch's destructor, and there's no way around that (unless we tap into talloc's internal structures). A way to workaround that would be to modify notmuch's API so that we can specify a destructor for notmuch objects, but that would be tedious, and I doubt a lof people beside us would benefit from that. In the meantime, it doesn't hurt to apply this patch. -- Felipe Contreras
Re: [PATCH] ruby: make sure the database is closed
On Tue, Apr 24, 2012 at 4:15 AM, Austin Clements wrote: > Quoth Felipe Contreras on Apr 24 at 3:45 am: >> On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: >> > 2012/4/24 Felipe Contreras : >> >> >> Personally I don't see why an object, like say a query would remain >> >> working correctly after the database is gone, either by calling >> >> .close() directly, or just loosing the pointer to the original object. >> >> I don't think users would expect that, or, even if they somehow found >> >> it useful, that most likely would be very seldom, and hardly worth >> >> worrying about it. >> > >> > Working correctly is not expected but wouldn't it be more appropriate >> > to throw an exception rather than dumping core or printing on standard >> > error? >> >> Sure, if that was possible. >> >> > I wonder whether we can make both work somehow. >> > Maybe by using talloc explicitly and keeping reference pointers? >> > I don't know whether it's worth bothering. >> >> Maybe, I don't see how, that's just not how C works. Maybe talloc does >> have some way to figure out if a pointer has been freed, but I doubt >> that, and I can't find it by grepping through the API. >> >> Another option would be hook into talloc's destructor so we know when >> an object is freed and taint it, but then we would be overriding >> notmuch's destructor, and there's no way around that (unless we tap >> into talloc's internal structures). A way to workaround that would be >> to modify notmuch's API so that we can specify a destructor for >> notmuch objects, but that would be tedious, and I doubt a lof people >> beside us would benefit from that. > > I believe (though I might be wrong) that bindings could simply > maintain their own talloc references to C objects returned by > libnotmuch to prevent them from being freed until the wrapper object > is garbage collected. This would require modifying all of the > library's _destroy functions to use talloc_find_parent_bytype and > talloc_unlink instead of simply calling talloc_free, but I don't think > this change would be particularly invasive and it certainly wouldn't > affect the library interface. That might work, but still, I don't see why this patch can't be applied. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 11:43 PM, Ali Polatel wrote: > 2012/4/23 Felipe Contreras : >> On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: >> >>> I'd rather not do this. >>> Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 >> >> OK, I've read this.. So? > > You are one step close to what I thought you had thought. I don't parse that. I meant that _now_ I've read it. >> The order in which Ruby's garbage-collector frees the database and >> other objects is irrelevant, because with this patch we are not >> manually freeing other objects, only the database. > > What I wanted was to make all objects "depending" on the database to be > unusable > once the database object is freed. Seeing that's not practically easy > I decided to leave > it to the user. Well, sure, but if the user has problems, the user can keep the database object around. Personally I don't see why an object, like say a query would remain working correctly after the database is gone, either by calling .close() directly, or just loosing the pointer to the original object. I don't think users would expect that, or, even if they somehow found it useful, that most likely would be very seldom, and hardly worth worrying about it. >> Sure, it's _better_ if the user calls close(), even better if it's >> inside an 'ensure', and even better if blocks are used (which I am >> using in most cases), but that's not *required*. > > If you have such a use case, I'm fine with that patch. > I might push it in the next few days or get someone else to push it. I did at some point, not sure if I do now. But that's beside the point, the point is that it really does happen. >> The user might just do: >> >> def foo >> ?db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) >> end >> >> That's perfectly fine in Ruby (although not ideal), since 'db' will >> get garbage-collected. But nobody will be able to use the database >> again until that process is killed. >> >> You think that's correct? > > Yes that is correct. I have not thought about this. > I'd say it's a partial misunderstanding on my part due to lack of > (and/or too much) vodka. Well, there's only two options. a) This works: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end (as in; the database gets closed eventually) b) This works: def start_query(search) db = Notmuch::Database.new($db_name) return db.query(search) end (as in; the query returned would keep working properly) I personally don't see why anybody would want b), and if they have problems with code like that, I think it's obvious to see why. I think we should go for a) and thus apply the patch. Cheers. -- Felipe Contreras
[PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > I'd rather not do this. > Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 OK, I've read this.. So? The order in which Ruby's garbage-collector frees the database and other objects is irrelevant, because with this patch we are not manually freeing other objects, only the database. Sure, it's _better_ if the user calls close(), even better if it's inside an 'ensure', and even better if blocks are used (which I am using in most cases), but that's not *required*. The user might just do: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end That's perfectly fine in Ruby (although not ideal), since 'db' will get garbage-collected. But nobody will be able to use the database again until that process is killed. You think that's correct? -- Felipe Contreras
Re: [PATCH] ruby: make sure the database is closed
On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: > 2012/4/24 Felipe Contreras : >> Personally I don't see why an object, like say a query would remain >> working correctly after the database is gone, either by calling >> .close() directly, or just loosing the pointer to the original object. >> I don't think users would expect that, or, even if they somehow found >> it useful, that most likely would be very seldom, and hardly worth >> worrying about it. > > Working correctly is not expected but wouldn't it be more appropriate > to throw an exception rather than dumping core or printing on standard error? Sure, if that was possible. > I wonder whether we can make both work somehow. > Maybe by using talloc explicitly and keeping reference pointers? > I don't know whether it's worth bothering. Maybe, I don't see how, that's just not how C works. Maybe talloc does have some way to figure out if a pointer has been freed, but I doubt that, and I can't find it by grepping through the API. Another option would be hook into talloc's destructor so we know when an object is freed and taint it, but then we would be overriding notmuch's destructor, and there's no way around that (unless we tap into talloc's internal structures). A way to workaround that would be to modify notmuch's API so that we can specify a destructor for notmuch objects, but that would be tedious, and I doubt a lof people beside us would benefit from that. In the meantime, it doesn't hurt to apply this patch. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom wrote: > /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 > -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE > ?-I/opt/local/include -fno-common -pipe -O2 -arch x86_64 ?-fno-common -pipe > -fno-common ?-arch x86_64 -c database.c Where is the output file defined? There should be a -o database.o there. Weird. This is what I have in my machine: gcc -I. -I/usr/include/ruby-1.9.1/x86_64-linux -I/usr/include/ruby-1.9.1/ruby/backward -I/usr/include/ruby-1.9.1 -I. -I../../lib -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -o messages.o -c messages.c -- Felipe Contreras
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
Re: [PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 11:43 PM, Ali Polatel wrote: > 2012/4/23 Felipe Contreras : >> On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: >> >>> I'd rather not do this. >>> Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 >> >> OK, I've read this.. So? > > You are one step close to what I thought you had thought. I don't parse that. I meant that _now_ I've read it. >> The order in which Ruby's garbage-collector frees the database and >> other objects is irrelevant, because with this patch we are not >> manually freeing other objects, only the database. > > What I wanted was to make all objects "depending" on the database to be > unusable > once the database object is freed. Seeing that's not practically easy > I decided to leave > it to the user. Well, sure, but if the user has problems, the user can keep the database object around. Personally I don't see why an object, like say a query would remain working correctly after the database is gone, either by calling .close() directly, or just loosing the pointer to the original object. I don't think users would expect that, or, even if they somehow found it useful, that most likely would be very seldom, and hardly worth worrying about it. >> Sure, it's _better_ if the user calls close(), even better if it's >> inside an 'ensure', and even better if blocks are used (which I am >> using in most cases), but that's not *required*. > > If you have such a use case, I'm fine with that patch. > I might push it in the next few days or get someone else to push it. I did at some point, not sure if I do now. But that's beside the point, the point is that it really does happen. >> The user might just do: >> >> def foo >> db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) >> end >> >> That's perfectly fine in Ruby (although not ideal), since 'db' will >> get garbage-collected. But nobody will be able to use the database >> again until that process is killed. >> >> You think that's correct? > > Yes that is correct. I have not thought about this. > I'd say it's a partial misunderstanding on my part due to lack of > (and/or too much) vodka. Well, there's only two options. a) This works: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end (as in; the database gets closed eventually) b) This works: def start_query(search) db = Notmuch::Database.new($db_name) return db.query(search) end (as in; the query returned would keep working properly) I personally don't see why anybody would want b), and if they have problems with code like that, I think it's obvious to see why. I think we should go for a) and thus apply the patch. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
[PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Hi,
On Sun, Apr 22, 2012 at 3:07 PM, Justus Winter
<4winter at informatik.uni-hamburg.de> wrote:
> Adapt the ruby bindings to the notmuch_database_close split.
>
> Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
> ---
> ?bindings/ruby/database.c | ? ?2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
> index 982fd59..ba9a139 100644
> --- a/bindings/ruby/database.c
> +++ b/bindings/ruby/database.c
> @@ -110,7 +110,7 @@ notmuch_rb_database_close (VALUE self)
> ? ? notmuch_database_t *db;
>
> ? ? Data_Get_Notmuch_Database (self, db);
> - ? ?notmuch_database_close (db);
> + ? ?notmuch_database_destroy (db);
> ? ? DATA_PTR (self) = NULL;
>
> ? ? return Qnil;
> --
I don't think this is the right approach. If database_destroy truly
destroys the object, then we would want to do it only at garbage
collection, when it's not accessible any more. What if I want to
re-use the database from the Ruby code?
This would probably be better:
-- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_destroy (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
Felipe Contreras
[ANN] New awesome vim plug-in using Ruby bindings
Hi, If you reply to all, remove Ryan Harper, as the address doesn't work. Or just reply here. Cheers. 2012/4/23 Felipe Contreras : > I've never been particularly happy with the code of the vim plug-in, > but it sort of did the job, after some fixes, and has been working > great so far for most of my needs even though it's clearly very rough > on the edges. > > However, I'm recently in need of been able to read HTML mails, and > just trying to add that code was a nightmare, so I decided to look for > alternatives, including Anton's Python vim plug-in (which is nice, but > doesn't have support for that), and even learning emacs, to use what > most people here use (but it turns out the HTML messages don't work > correctly there either). I also tried the various mutt+notmuch > options, and none fit the bill. > > So, since I'm a big fan of Ruby, I decided to try my luck writing a > plug-in from scratch. It took me one weekend, but I'm pretty happy > with the result. This plug-in has already essentially all the > functionality of the current one, but it's much, *much* simpler (only > 600) lines of code. > > And in addition has many more features: > > ?* Gradual searches; you don't have to wait for the whole search to finish, > ? sort of like the 'less' command > ?* Proper multi-part handling; finds out if there's text/plain, or if > ? text/html, converts it using elinks > ?* Extract all attachments > ?* Open message with mutt (or any external application that can open an mbox) > ?* More proper UTF-8 handling > ?* Configurable key mappings > ?* Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) > > I just added support to reply mails today, and after trying a bit I > got complaints from the vger.kernel.org server, but people using mutt > have had the same complaint, so I don't know, I wouldn't reply totally > on that. *But* you can open the mail with mutt, or any other client > that you want, as a fall-back option (the command to run is > configurable). > > Sure, it depends on the Ruby bindings from notmuch (but those are easy > to compile), and on the 'mail' library from Ruby (easy to install), > but it makes things much, *much* easier. There might be ways to make > certain dependencies optional, and make this, and the current plug-in > converge somehow (maybe even the python one too), but for now I don't > see any reason to look back. > > I can't wait to start using it for real :) > > Enjoy ;) > > https://github.com/felipec/notmuch-vim-ruby > > P.S. I CC'ed a bunch of people that have showed interest in the vim > interface, I hope you don't mind -- Felipe Contreras
[ANN] New awesome vim plug-in using Ruby bindings
On Mon, Apr 23, 2012 at 6:41 AM, Adam Wolfe Gordon wrote: > Hi Felipe, > > This work sounds nice - it's good to have lots of interface choices. > One question below: > > On Sun, Apr 22, 2012 at 19:12, Felipe Contreras > wrote: >> doesn't have support for that), and even learning emacs, to use what >> most people here use (but it turns out the HTML messages don't work >> correctly there either). I also tried the various mutt+notmuch > > HTML emails should work properly in emacs, and work even better if you > have w3.el installed. Replying to HTML emails isn't in git yet, but > there are patches for it in progress [1]. If there's a bug in the HTML > support, we should probably fix it, so could you explain what doesn't > work for you? I do have w3.el installed. I can read the HTML, but when scrolling and selecting there are glitches, and when replying nothing gets quoted. Cheers. -- Felipe Contreras
Re: [PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > I'd rather not do this. > Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 OK, I've read this.. So? The order in which Ruby's garbage-collector frees the database and other objects is irrelevant, because with this patch we are not manually freeing other objects, only the database. Sure, it's _better_ if the user calls close(), even better if it's inside an 'ensure', and even better if blocks are used (which I am using in most cases), but that's not *required*. The user might just do: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end That's perfectly fine in Ruby (although not ideal), since 'db' will get garbage-collected. But nobody will be able to use the database again until that process is killed. You think that's correct? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom wrote: > /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 > -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE > -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe > -fno-common -arch x86_64 -c database.c Where is the output file defined? There should be a -o database.o there. Weird. This is what I have in my machine: gcc -I. -I/usr/include/ruby-1.9.1/x86_64-linux -I/usr/include/ruby-1.9.1/ruby/backward -I/usr/include/ruby-1.9.1 -I. -I../../lib -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -o messages.o -c messages.c -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
