Re: no pthread_spinlock_t on Mac OS 10.6.4

Hi Paul, Thanks for looking at this. On 20 Sep 2010, at 13:21, Paul Eggert wrote: > On 09/19/2010 07:43 PM, Gary V. Vaughan wrote: >> my system headers have no pthread_spinlock_t definition, but >> gnulib sees /usr/include/pthread.h and uses that instead of generating it's >> own, >> ... >> I do

Re: build-aux confusion

On 20 September 2010 01:27, Karl Berry wrote: >    Honestly, what is the problem with gnulib-tool? Why do you find it >    hard to understand? > > Personally, I think g-t is about as well written as anything of its size > and purpose could be, but 6000 lines of anything is not prima facie > obviou

Re: no pthread_spinlock_t on Mac OS 10.6.4

Hi Paul, > If MacOS doesn't have spinlocks, then from coreutils' point of view MacOS > doesn't have proper thread support. Usually in applications mutexes are used, not spinlocks. The comments in sort.c say: "Note spin locks were seen to perform better than mutexes as long as the number of

Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

On 20/09/10 07:21, Paul Eggert wrote: > On 09/19/2010 07:43 PM, Gary V. Vaughan wrote: >> my system headers have no pthread_spinlock_t definition, but >> gnulib sees /usr/include/pthread.h and uses that instead of generating it's >> own, >> ... >> I don't know enough about pthreads to tell whethe

Re: new module 'regex-quote'

On 09/18/2010 04:05 PM, Bruno Haible wrote: /* regex_quote converts a literal string to a regular expression that will look for this literal string. cflags can be 0 or REG_EXTENDED. If it is 0, the result is a Basic Regular Expression (BRE)

Re: new module 'regex-quote'

On 18 September 2010 23:53, Reuben Thomas wrote: > Great, thanks, though at 3 new functions and about 50 lines of code it > does illustrate why I prefer RE_PLAIN. > > Nonetheless, if you put this in gnulib I'd probably use it rather than > RE_PLAIN, just because it's there. On second thoughts, --

Re: A fix for pmccabe2html

On 09/19/2010 04:54 PM, Reuben Thomas wrote: After investigation, I think I found the bug: cut_dir should not be hardwired to "/../", but rather set to "${top_srcdir}/". Otherwise, it does not work for a typical in-tree build: cut_dir is not found in the path, index returns 0, and an arbitrary fe

Re: module libposix

Hi Bruno, On Sat, Sep 18, 2010 at 5:21 PM, Bruno Haible wrote: >> >   ./build-aux/git-version-gen /dev/null | sed -e 's/-dirty/-modified/' >> >> "UNKNOWN-modified"?  I don't know how you'd want to see that worked >> into a version number. > > Hmm, for me that command prints >  0.0.4280-882da > Is

Re: module libposix

On 09/20/2010 09:13 AM, Bruce Korb wrote: I took a quick look. The problem is that "git-version-gen" knows that it must be running in the gnulib root directory. If it is not, it just quietly inserts "UNKNOWN" into the output. This script should add this code early on: cd_to_git_root() { t

Re: module libposix

Hi, On Mon, Sep 20, 2010 at 8:33 AM, Eric Blake wrote: > On 09/20/2010 09:13 AM, Bruce Korb wrote: >> >> I took a quick look.  The problem is that "git-version-gen" knows >> that it must be running in the gnulib root directory.  If it is not, >> it just quietly inserts "UNKNOWN" into the output.

Re: new module 'regex-quote'

Hi Eric, > > /* regex_quote converts a literal string to a regular expression that will > > look for this literal string. > > cflags can be 0 or REG_EXTENDED. > > If it is 0, the result is a Basic Regular Expression (BRE) > > > >

Re: new module 'regex-quote'

On 09/20/2010 10:21 AM, Bruno Haible wrote: Hi Eric, /* regex_quote converts a literal string to a regular expression that will look for this literal string. cflags can be 0 or REG_EXTENDED. If it is 0, the result is a Basic Regular Expression (BRE)

Re: no pthread_spinlock_t on Mac OS 10.6.4

On 09/20/10 00:14, Gary V. Vaughan wrote: > lib/pthread.h does have a typedef for pthread_spinlock_t, but it is > predicated on not having HAVE_PTHREAD_T defined (which I do): Ah, OK. Could you try the following patch instead? If you have a similar problem with (say) pthread_rwlockattr_t, you

Re: no pthread_spinlock_t on Mac OS 10.6.4

On 09/20/10 02:24, Bruno Haible wrote: > why not use mutexes instead of spinlocks on this platform? That might be a good thing to try, though it'd take more work. Chen, what do you think? Here's the email that started this discussion: http://lists.gnu.org/archive/html/bug-coreutils/2010-09/msg00

Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

On 09/20/10 02:33, Pádraig Brady wrote: > On a related note, I've been meaning to check > if mutexes in coreutils/sort are more stable > and/or fair to the system than spinlocks. They ought to be fairer, though I'd expect there to be a significant performance price in some cases. I'm not sure wha

Re: new module 'regex-quote'

Eric, > rather than adding a new flag bit, what about providing > regex_quote_anchored as a wrapper that provides the anchors, so that the > end user can choose between the one-liners of regex_quote or > regex_quote_anchored? It's the same argumentation: It's already easy enough to do this in

Re: new module 'regex-quote'

> The drawback of a large API is that it's harder to keep in memory. "keep in mind". "memory" as in "computer memory" is too cheap to be any consideration at all. :)

Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

Hi all, First regarding mutexes on Macs, I suppose a performance hit with mutexes beats no performance at all with missing spinlocks. And regarding "take more work," I believe spinlocks and mutexes were basically interchangeable in terms of functionality in our sort algorithm; the work probably wi

Re: new module 'regex-quote'

On 20 September 2010 19:21, Bruno Haible wrote: > The drawback of a large API is that it's harder to keep in memory. Heh. My point precisely: 3 functions and 50 lines versus 1 flag and 5 lines (RE_PLAIN) to solve the same problem (although my solution does not help with the anchored variant, but

Re: A fix for pmccabe2html

On 20 September 2010 15:49, Eric Blake wrote: > Rather than describing the fix, could you post this as a patch? Sorry; you've made me realise that my habit of not posting patches for code I'm not sure about is silly for several reasons. Patch attached. I've added an Emacs mode-setting line to th

Another minor patch to pmccabe2html

Attached, to make the whitespace in the Makefile.am example more copy-and-paste friendly. By the way, is there some reason to keep this file and pmccabe.css in gnulib rather than push it upstream to pmccabe, and make the gnulib module just make the test and suggest an appropriate Makefile.am patch

[PATCH] pthread: add pthread_spin_destroy

* lib/pthread.in.h (pthread_spin_destroy): New function. --- ChangeLog|5 + lib/pthread.in.h |7 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 307a58a..ec48b91 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2010-09-

Re: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

On 09/20/10 14:38, Chen Guo wrote: > How difficult would it be to implement a basic spinlock in gnulib, though? Portably? I'd think it'd be quite a pain, as it would require figuring out this platform's atomic instructions, dealing with memory barriers, and the like. > I suppose a performance h

Re: new module 'regex-quote'

Reuben, > Heh. My point precisely: 3 functions and 50 lines versus 1 flag and 5 > lines (RE_PLAIN) to solve the same problem I agree that if we had the opportunity to invent regex APIs from scratch now, all 4 syntaxes (literals, wildcards, basic regular expression, extended regular expression) wo

Re: no pthread_spinlock_t on Mac OS 10.6.4

Hi Paul, On 21 Sep 2010, at 00:30, Paul Eggert wrote: > On 09/20/10 00:14, Gary V. Vaughan wrote: > >> lib/pthread.h does have a typedef for pthread_spinlock_t, but it is >> predicated on not having HAVE_PTHREAD_T defined (which I do): > > Ah, OK. Could you try the following patch instead? Th