emacs complains about encoding?
On Wed, May 23, 2012 at 4:15 AM, Michal Sojka wrote: >> I think the current plan is to use the same decoding lookup table that >> notmuch-show is using in reply too. > > Which table do you refer to? notmuch-show-handlers-for? Yep, that looks like the right thing. I've been particularly busy with work and other things lately, so I haven't had time to get this change done. If someone else wants to work on this I'll be happy to review it; otherwise I'll try to get it done in the next few weeks. Tomi's gnus-decoded fix went into 0.13.1 anyway, so I don't think the rest is particularly urgent. -- Adam
Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 11:01 AM, Jameson Graef Rollins wrote: > On Fri, Jun 01 2012, David Bremner wrote: >> I guess we should clarify what it means to accept some code into >> contrib. Do we accept to maintain it even after the original contributor >> loses interest? > > 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. +1. I think having the bindings in the tree and including them in build system is reasonable, since they're interfaces into the core of the notmuch library. We should be careful of what bindings we accept in to the tree (I don't want to fix Fortran bindings ;-) ), but the small set we have seems maintainable. It's harder to make a case for contrib. Keeping stuff that relies on notmuch up-to-date is a nice idea, but doing so creates more work for developers working on the library and core, since they have to fix a bunch of code they're not that familiar with. Things that are actively used (e.g. alot) will be updated quickly anyway since their developers will tend to keep up with what notmuch is doing. -- Adam
Re: emacs complains about encoding?
On Wed, May 23, 2012 at 4:15 AM, Michal Sojka wrote: >> I think the current plan is to use the same decoding lookup table that >> notmuch-show is using in reply too. > > Which table do you refer to? notmuch-show-handlers-for? Yep, that looks like the right thing. I've been particularly busy with work and other things lately, so I haven't had time to get this change done. If someone else wants to work on this I'll be happy to review it; otherwise I'll try to get it done in the next few weeks. Tomi's gnus-decoded fix went into 0.13.1 anyway, so I don't think the rest is particularly urgent. -- Adam ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Can't compile notmuch-delivery
On Fri, Jun 1, 2012 at 11:01 AM, Jameson Graef Rollins wrote: > On Fri, Jun 01 2012, David Bremner wrote: >> I guess we should clarify what it means to accept some code into >> contrib. Do we accept to maintain it even after the original contributor >> loses interest? > > 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. +1. I think having the bindings in the tree and including them in build system is reasonable, since they're interfaces into the core of the notmuch library. We should be careful of what bindings we accept in to the tree (I don't want to fix Fortran bindings ;-) ), but the small set we have seems maintainable. It's harder to make a case for contrib. Keeping stuff that relies on notmuch up-to-date is a nice idea, but doing so creates more work for developers working on the library and core, since they have to fix a bunch of code they're not that familiar with. Things that are actively used (e.g. alot) will be updated quickly anyway since their developers will tend to keep up with what notmuch is doing. -- Adam ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
bug in configure script
On Fri, Jun 01 2012, Jameson Graef Rollins wrote: > There's a bug in the configure script that is causing auto-reruns of > ./configure to not inherit original command line options if there was > more than one. For instance, if I run: > > ./configure --with-gmime-version=2.4 --prefix=/home/jrollins/opt/notmuch > > Then in Makefile.config I get: > > configure_options = > --with-gmime-version=2.4--prefix=/home/jrollins/opt/notmuch > > This means that auto-reruns of configure will not get the proper > options. > > I tracked this down to an issue with IFS and /bin/sh. The first line of > ./configure is: > > readonly DEFAULT_IFS=$IFS > > DEFAULT_IFS is then used to reset IFS after it is modified within the > script. The problem is that /bin/sh is setting DEFAULT_IFS to be NULL > (i.e. ''), which leads to no separation between variables when "$@" is > expanded (which is itself problematic since I don't think "@" should use > the IFS when expanded). So this might be a bug in dash. I don't know. > In any event we need to fix this somehow. dash manual states that readonly name=value should work, but it seems to have some side effects. I tried some alternatives on command line: $ readonly FOO1=$IFS $ echo "$FOO1" | od -f x1 000 0a 001 $ readonly FOO2="$IFS" $ echo "$FOO2" | od -f x1 000 20 09 0a 0a 004 $ FOO3=$IFS $ readonly FOO3 $ echo "$FOO4" | od -f x1 000 20 09 0a 0a 004 I.e. in dash 'readonly name=$value' $value gets expanded like it was given in command line and not when just doing variable assignment. Easiest is just to drop the 'readonly'; too bad it caused problems :( (I have to go now -- but I'll make a patch later unless someone beats me by doing it sooner ;) Tomi > I see two obvious solutions: > > * use /bin/bash. This a one line diff that fixes the problem > immediately. > > * replace: > > IFS=$DEFAULT_IFS > > with: > > unset IFS > > Unsetting IFS also resets IFS to the default, without going through > this intermediate step. > > I'm ok with either solution, but I'll wait for some feedback since I > imagine someone will have an opinion. > > jamie. > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in configure script
On Sat, Jun 02 2012, Tomi Ollila wrote: > I tried some alternatives on command line: > > $ readonly FOO1=$IFS > $ echo "$FOO1" | od -f x1 > 000 0a > 001 > > $ readonly FOO2="$IFS" > $ echo "$FOO2" | od -f x1 > 000 20 09 0a 0a > 004 > > $ FOO3=$IFS > $ readonly FOO3 > $ echo "$FOO4" | od -f x1 > 000 20 09 0a 0a > 004 I think there must have been some copy/paste or transcription error here? FOO4 isn't something that you had previous set (or at least not in what is shown). In any event, it's clear from your second example that all we needed to do was just quote the IFS when saving. That fixed the problem for me, so I submitted a patch. I'm ashamed I didn't just see that solution right off the bat. Thanks for the inspiration, Tomi. jamie. pgpFzrNyl8ybq.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
bug in configure script
On Sat, Jun 02 2012, Tomi Ollila wrote: > I tried some alternatives on command line: > > $ readonly FOO1=$IFS > $ echo "$FOO1" | od -f x1 > 000 0a > 001 > > $ readonly FOO2="$IFS" > $ echo "$FOO2" | od -f x1 > 000 20 09 0a 0a > 004 > > $ FOO3=$IFS > $ readonly FOO3 > $ echo "$FOO4" | od -f x1 > 000 20 09 0a 0a > 004 I think there must have been some copy/paste or transcription error here? FOO4 isn't something that you had previous set (or at least not in what is shown). In any event, it's clear from your second example that all we needed to do was just quote the IFS when saving. That fixed the problem for me, so I submitted a patch. I'm ashamed I didn't just see that solution right off the bat. Thanks for the inspiration, Tomi. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120602/b9814ba6/attachment.pgp>
[PATCH] config: add quoting to fix IFS bug
Without proper quoting the DEFAULT_IFS was getting set incorrectly, which was causing problems with the storage of some variables later in the script. Quoting fixes the problem. --- Thanks to Tomi for the inspiration for this fix. I don't know how I missed such a simple solution initially. configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 5602be2..3fad424 100755 --- a/configure +++ b/configure @@ -1,7 +1,7 @@ #! /bin/sh # Store original IFS value so it can be changed (and restored) in many places. -readonly DEFAULT_IFS=$IFS +readonly DEFAULT_IFS="$IFS" srcdir=$(dirname "$0") -- 1.7.10 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] config: add quoting to fix IFS bug
Without proper quoting the DEFAULT_IFS was getting set incorrectly, which was causing problems with the storage of some variables later in the script. Quoting fixes the problem. --- Thanks to Tomi for the inspiration for this fix. I don't know how I missed such a simple solution initially. configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 5602be2..3fad424 100755 --- a/configure +++ b/configure @@ -1,7 +1,7 @@ #! /bin/sh # Store original IFS value so it can be changed (and restored) in many places. -readonly DEFAULT_IFS=$IFS +readonly DEFAULT_IFS="$IFS" srcdir=$(dirname "$0") -- 1.7.10
Re: bug in configure script
On Fri, Jun 01 2012, Jameson Graef Rollins wrote: > There's a bug in the configure script that is causing auto-reruns of > ./configure to not inherit original command line options if there was > more than one. For instance, if I run: > > ./configure --with-gmime-version=2.4 --prefix=/home/jrollins/opt/notmuch > > Then in Makefile.config I get: > > configure_options = > --with-gmime-version=2.4--prefix=/home/jrollins/opt/notmuch > > This means that auto-reruns of configure will not get the proper > options. > > I tracked this down to an issue with IFS and /bin/sh. The first line of > ./configure is: > > readonly DEFAULT_IFS=$IFS > > DEFAULT_IFS is then used to reset IFS after it is modified within the > script. The problem is that /bin/sh is setting DEFAULT_IFS to be NULL > (i.e. ''), which leads to no separation between variables when "$@" is > expanded (which is itself problematic since I don't think "@" should use > the IFS when expanded). So this might be a bug in dash. I don't know. > In any event we need to fix this somehow. dash manual states that readonly name=value should work, but it seems to have some side effects. I tried some alternatives on command line: $ readonly FOO1=$IFS $ echo "$FOO1" | od -f x1 000 0a 001 $ readonly FOO2="$IFS" $ echo "$FOO2" | od -f x1 000 20 09 0a 0a 004 $ FOO3=$IFS $ readonly FOO3 $ echo "$FOO4" | od -f x1 000 20 09 0a 0a 004 I.e. in dash 'readonly name=$value' $value gets expanded like it was given in command line and not when just doing variable assignment. Easiest is just to drop the 'readonly'; too bad it caused problems :( (I have to go now -- but I'll make a patch later unless someone beats me by doing it sooner ;) Tomi > I see two obvious solutions: > > * use /bin/bash. This a one line diff that fixes the problem > immediately. > > * replace: > > IFS=$DEFAULT_IFS > > with: > > unset IFS > > Unsetting IFS also resets IFS to the default, without going through > this intermediate step. > > I'm ok with either solution, but I'll wait for some feedback since I > imagine someone will have an opinion. > > jamie. > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Can't compile notmuch-delivery
Quoting David Bremner (2012-06-01 20:46:59) > Jameson Graef Rollins writes: > > > I think the zeroth-order thing we have to do then is to have the build > > include the bindings as well. Then everyone will be able to see > > immediately if the bindings are broken. I wouldn't even make it an > > option, or make it an option to exclude building the bindings rather > > than to include. > > OK, I can agree with this. Can we get some help from the bindings > maintainers (or other interested people) in getting this working? > Probably configure should detect/decide what bindings to build. I like the idea. The thing with the python bindings is that building them wont detect any errors, one has to import the module. Quick and dirty python oneliner that doesn't even require installing the bindings: teythoon at thinkbox ~/repos/notmuch (git)-[master] % ( export LD_LIBRARY_PATH="$(pwd)/lib" ; cd bindings/python && python -c "import notmuch" ) Traceback (most recent call last): File "", line 1, in File "notmuch/__init__.py", line 54, in from .database import Database File "notmuch/database.py", line 46, in class Database(object): File "notmuch/database.py", line 76, in Database _get_directory = nmlib.notmuch_database_get_directory_b0rked File "/usr/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__ func = self.__getitem__(name) File "/usr/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: /home/teythoon/repos/notmuch/lib/libnotmuch.so.3: undefined symbol: notmuch_database_get_directory_b0rked Justus
