date:20120301

Re: Experiments with Git

2012-03-01 Thread Jason Smith

On Thu, Mar 1, 2012 at 2:39 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 However I don't think it's OK to ask for  a branch / fix especially
 when diff  200 LOC even if we use branch locally.

Yes I agree wholeheartedly.

We should not ask for a branch when it is a small issue.

-- 
Iris Couch

Crash of CouchDB 1.2.x

2012-03-01 Thread Stefan Kögl

Hello,

My experiments to replicate some live data / traffic to a CouchDB
1.2.x (running the current 1.2.x branch + the patch from [1]) that
sparked the indexing speed discussions, did also yield another
(potential) problem. First sorry for not further reporting back any
performance measurements, but I didn't yet find the time to run the
tests on my machines.

Anyway, I found the following stack traces in my log (after noticing
that some requests failed and compaction of a view stopped)

http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt

The files starts at the first failed requests. Every request before
that returned a positiv (ie 2xx) status code. The crash might have
some natural reason (such as timeouts, lack of RAM, etc), but I'm
not sure how to interpret Erlang stack traces. Can somebody point me
in the right direction for diagnosing the problem?


Thanks,

-- Stefan


[1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Guide Champagne Euvrard Garnier - Edition 2012

2012-03-01 Thread Vinomedia




Si vous n'arrivez pas à ouvrir ce mail, consultez sa version en ligne
http://www.vinomedia.fr/emailing/vinomedia-publishing/guide_euvrard2012
.htm 

 
http://www.vinomedia.fr/emailing/vinomedia-publishing/guide%20euvrard20
12/images/email_01.jpg 
 
http://www.vinomedia.fr/emailing/vinomedia-publishing/guide%20euvrard20
12/images/email_02.jpg Accéder à la vente
http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3434click_ema
il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009
5f83760f1click_url=http://www.vinomedia-publishing.com/produit.asp?pr_i
d_produit=62
http://www.vinomedia.fr/emailing/vinomedia-publishing/guide%20euvrard20
12/images/email_04.jpg 
 
http://www.vinomedia.fr/emailing/vinomedia-publishing/guide%20euvrard20
12/images/email_05.jpg 


Conformément à la loi N° 78-17 du 6 janvier 1978, vous pouvez demander à
être retiré de cette liste.
Pour vous désinscrire et ne plus recevoir de messages de notre part
cliquez ici
http://optout.vinsprimeurs.com/parseOut.asp?cn_id_cmp=3434cn_email=cou
chdb-dev%40incubator.apache.orgcn_diug=1355a90fb5ab56f7ba9b0095f83760f1
cn_id_tneilc=10 ,
dans le cas contraire nous considérerons que vous acceptez de les
recevoir. 
 
http://mailing.vinsprimeurs.com/img.asp?hit_id_cmp=3434hit_email=couch
db-dev%40incubator.apache.org

Re: Experiments with Git

2012-03-01 Thread Jan Lehnardt

I'd say, branch away!


On Mar 1, 2012, at 01:27 , Jason Smith wrote:

 Hi, all.
 
 I hope you will pardon my commits to the repository. My plan is to try
 to stumble upon some useful custom or workflow. Please let me know if
 you have feedback or views.
 
 Piggybacking off of Randall's idea, I have made a branch for every
 JIRA ticket that I am interested or involved in. I would personally
 like to see more branching and merging in the repo--to see it look
 less like a Subversion timeline.
 
 Once 1.2 is out, I also intend to push some feature branches, with no
 intention for short-term merging, just to get them out there in the
 open. I hope Benoit might push up some refuge  work, or others can
 exercise their branches similarly.

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Jan Lehnardt

Hi Stefan,

thanks for the report, this is very helpful!

Can you tell us how you installed 1.2.x? Is it a fresh installation,
did you do an in-place update from an earlier installation (earlier
1.2.x or 1.1.x or 1.0.x?

Without having dug too much yet and more as a pointer for the other
devs here, I remember seeing io_lib_* errors in cases where we catch
exceptions in an attempt to make prettier messages, but then the
catch-all clause tries to print whatever is actually unexpected
and fails there, resulting in the io_lib_* stacktrace when
attempting to print the actual stacktrace that subsequently
gets lost.

Cheers
Jan
-- 



On Mar 1, 2012, at 12:17 , Stefan Kögl wrote:

 Hello,
 
 My experiments to replicate some live data / traffic to a CouchDB
 1.2.x (running the current 1.2.x branch + the patch from [1]) that
 sparked the indexing speed discussions, did also yield another
 (potential) problem. First sorry for not further reporting back any
 performance measurements, but I didn't yet find the time to run the
 tests on my machines.
 
 Anyway, I found the following stack traces in my log (after noticing
 that some requests failed and compaction of a view stopped)
 
 http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt
 
 The files starts at the first failed requests. Every request before
 that returned a positiv (ie 2xx) status code. The crash might have
 some natural reason (such as timeouts, lack of RAM, etc), but I'm
 not sure how to interpret Erlang stack traces. Can somebody point me
 in the right direction for diagnosing the problem?
 
 
 Thanks,
 
 -- Stefan
 
 
 [1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Re: git commit: fix build with custom path - close #COUCHDB-1426

2012-03-01 Thread Paul Davis

A few hunks in here concern me:

-CPPFLAGS=$CPPFLAGS -I/opt/local/include/js
CPPFLAGS=$CPPFLAGS -I/usr/local/include
-CPPFLAGS=$CPPFLAGS -I/usr/local/include/js
CPPFLAGS=$CPPFLAGS -I/usr/include
-CPPFLAGS=$CPPFLAGS -I/usr/include/js

I remember having to add some of these for extremely specific
scenarios. Are we absolutely sure this isn't going to lead to a
regression for some people?

+AC_MSG_RESULT(js flags $CPPFLAGS)
+

This syntax looks weird to me. Its probably right but does anyone know
the rules on when strings need square brackets?

+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+   #include jsconfig.h
+   ]],
+   [[
+#if JS_VERSION == 170
+// Use spidermonkey 1.7.0
+#else
+# Not Spidermonkey 1.7.0
+#endif
+]])],
+[use_js170=yes],
+[])

Please don't invent a new indentation scheme for random hunks in a
patch. Also, what's actually being tested here? I'm not seeing how
this would fail unless we're depending on jsconfig.h only existing in
1.7.0 builds, in which case a test compile is not the way to run this
check.

Everything after that hunk looks quite weird to me. I'm fairly certain
we just had a commit that fixes this issue. I don't remember the
details off the top of my head but this is getting into the land of
silly walks with all the bending over backwards to find SpiderMonkey.
At a certain point we might want to just ixnay a lot of this and just
guess at the most common cases and if we can't find a version then we
should just add a configure option.

On Wed, Feb 29, 2012 at 6:01 PM,  j...@apache.org wrote:
 Updated Branches:
  refs/heads/COUCHDB-1426 [created] 56a00ede8


 fix build with custom path - close #COUCHDB-1426

 This patch make sure that js libs and include given using the options
 --with-js-lib and --with-js-include are used in priority, ie before the
 detection of the version. Also if spidermonkey 1.7.0 is detected it
 removes useless tests.


 Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
 Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/56a00ede
 Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/56a00ede
 Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/56a00ede

 Branch: refs/heads/COUCHDB-1426
 Commit: 56a00ede8ab237fc3b2c1a3ea23a688e5aa997c0
 Parents: 766d461
 Author: benoitc beno...@apache.org
 Authored: Thu Mar 1 00:16:14 2012 +0100
 Committer: Jason Smith (air) j...@apache.org
 Committed: Wed Feb 29 23:59:55 2012 +

 --
  configure.ac |  128 +
  1 files changed, 80 insertions(+), 48 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/couchdb/blob/56a00ede/configure.ac
 --
 diff --git a/configure.ac b/configure.ac
 index 7ce4842..e526a18 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -137,13 +137,33 @@ AC_ARG_WITH([erlang], 
 [AC_HELP_STRING([--with-erlang=PATH],
  ])
  AC_SUBST(ERLANG_FLAGS)

 -PKG_CHECK_MODULES([JS], [mozjs185], [
 +AC_ARG_WITH([js-lib], [AC_HELP_STRING([--with-js-lib=PATH],
 +            [set PATH to the SpiderMonkey library directory])],
 +    [
 +    JS_LIB_DIR=$withval
 +    JS_LIBS=-L$JS_LIB_DIR
 +    AC_MSG_RESULT(yo $JS_LIBS)
 +], [
 +    PKG_CHECK_MODULES([JS], [mozjs185], [
     JS_LIB_DIR=$(${PKG_CONFIG} --variable=libdir mozjs185)
 +    ], [
 +        PKG_CHECK_MODULES([JS], [mozilla-js = 1.7], [
 +            JS_LIB_DIR=$(${PKG_CONFIG} --variable=sdkdir mozilla-js)/lib
 +        ], [
 +            JS_LIB_DIR=${libdir}
 +        ])
 +    ])
 +])
 +
 +
 +AC_ARG_WITH([js-include], [AC_HELP_STRING([--with-js-include=PATH],
 +    [set PATH to the SpiderMonkey include directory])], [
 +    JS_INCLUDE=$withval
 +    JS_CFLAGS=-I$JS_INCLUDE
  ], [
     PKG_CHECK_MODULES([JS], [mozilla-js = 1.7], [
 -        JS_LIB_DIR=$(${PKG_CONFIG} --variable=sdkdir mozilla-js)/lib
 +        JS_CFLAGS=$(${PKG_CONFIG} --variable=includedir mozilla-js)/lib
     ], [
 -        JS_LIB_DIR=${libdir}
         JS_CFLAGS=-I/usr/include
         JS_CFLAGS=$JS_CFLAGS -I/usr/include/js
         JS_CFLAGS=$JS_CFLAGS -I/usr/include/mozjs
 @@ -152,19 +172,6 @@ PKG_CHECK_MODULES([JS], [mozjs185], [
     ])
  ])

 -AC_ARG_WITH([js-include], [AC_HELP_STRING([--with-js-include=PATH],
 -    [set PATH to the SpiderMonkey include directory])], [
 -    JS_INCLUDE=$withval
 -    JS_CFLAGS=-I$JS_INCLUDE
 -], [])
 -
 -AC_ARG_WITH([js-lib], [AC_HELP_STRING([--with-js-lib=PATH],
 -    [set PATH to the SpiderMonkey library directory])],
 -    [
 -    JS_LIB_DIR=$withval
 -    JS_LIBS=-L$withval
 -], [])
 -
  use_js_trunk=no
  AC_ARG_ENABLE([js-trunk],

Re: Please report your indexing speed

2012-03-01 Thread Wendall Cada


Here are my 1.1.1 results on the same hardware/kernel/spidermonkey:

{couchdb:Welcome,version:1.1.1}
real0m32.029s
user0m0.000s
sys 0m0.006s

Wendall

On 02/29/2012 01:30 PM, Robert Newson wrote:

Benoit, could you run the 1.7.0 test for longer? Say, double the size
of BULK_COUNT?

Wendall, that's a useful new data point. Any chance you could compare
1.1.1 with 1.2 so we can line it up with the other results?

B.

On 29 February 2012 19:40, Wendall Cadawenda...@83864.com  wrote:

I'm using the bash script provided by Robert Newson.

Linux version 3.2.7-1.fc16.i686.PAE
(mockbu...@x86-16.phx2.fedoraproject.org) (gcc version 4.6.2 20111027 (Red
Hat 4.6.2-1) (GCC) )
spidermonkey 1.8.5
i686

{couchdb:Welcome,version:1.0.3} (from stock fedora rpm Release:
2.fc16)
real0m35.652s
user0m0.001s
sys 0m0.006s

{couchdb:Welcome,version:1.2.0} git 4cd60f3d1683
real0m20.134s
user0m0.002s
sys 0m0.004s

Wendall


On 02/28/2012 05:17 AM, Jason Smith wrote:

Forgive the clean new thread. Hopefully it will not remain so.

If you can, would you please clone https://github.com/jhs/slow_couchdb

And build whatever Erlangs and CouchDB checkouts you see fit, and run
the test. For example:

 docs=50 ./bench.sh small_doc.tpl

That should run the test and, God willing, upload the results to a
couch in the cloud. We should be able to use that information to
identify who you are, whether you are on SSD, what Erlang and Couch
build, and how fast it ran. Modulo bugs.

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Stefan Kögl

On Thu, Mar 1, 2012 at 4:52 PM, Jan Lehnardt j...@apache.org wrote:
 Can you tell us how you installed 1.2.x? Is it a fresh installation,
 did you do an in-place update from an earlier installation (earlier
 1.2.x or 1.1.x or 1.0.x?

I first did a fresh install of 1.2.x using R15B. I then removed R15B,
installed R14B04 (both from source), compiled 1.2.x with the patch I
mentioned earlier, and did an in-place update.

If this is a problem, I could remove CouchDB first and do a fresh
install instead. What would be the preferred way to do a clean
uninstall?


-- Stefan


 On Mar 1, 2012, at 12:17 , Stefan Kögl wrote:

 Hello,

 My experiments to replicate some live data / traffic to a CouchDB
 1.2.x (running the current 1.2.x branch + the patch from [1]) that
 sparked the indexing speed discussions, did also yield another
 (potential) problem. First sorry for not further reporting back any
 performance measurements, but I didn't yet find the time to run the
 tests on my machines.

 Anyway, I found the following stack traces in my log (after noticing
 that some requests failed and compaction of a view stopped)

 http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt

 The files starts at the first failed requests. Every request before
 that returned a positiv (ie 2xx) status code. The crash might have
 some natural reason (such as timeouts, lack of RAM, etc), but I'm
 not sure how to interpret Erlang stack traces. Can somebody point me
 in the right direction for diagnosing the problem?


 Thanks,

 -- Stefan


 [1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Filipe Manana (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220225#comment-13220225
]

Filipe Manana commented on COUCHDB-1426:

Thanks Benoît.

Tried the latest patch, there seems to be a syntax error:

./configure: line 16477: syntax error near unexpected token `('
./configure: line 16477: ` echo $ECHO_N (cached) $ECHO_C 6'

error while building with 2 spidermonkey installed
--

Key: COUCHDB-1426
URL: https://issues.apache.org/jira/browse/COUCHDB-1426
Project: CouchDB
Issue Type: Bug
Components: Build System
Affects Versions: 1.1.1, 1.2
Reporter: Benoit Chesneau
Priority: Blocker
Attachments:
0001-fix-build-with-custom-path-close-COUCHDB-1426.patch,
0001-fix-build-with-custom-path-close-COUCHDB-1426.patch,
0001-fix-build-with-custom-path-close-COUCHDB-1426.patch

Context:
To bench the differences between different versions of couchdb I had to test
against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in
/usr/local while the 1.7 version is installed on a temporary path.
Problem:
Using --witth-js-include --with-js-lib configure options aren't enough to
use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing
js-config from the path doesn't change anything. I had to uninstall
spidermonkey 1.8.5 to have these setting working.
Error result:
$ ./configure
--with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include
--with-js-include=/Users/benoitc/local/js-1.7.0/include
--with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i386-apple-darwin11.3.0
checking host system type... i386-apple-darwin11.3.0
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc...
/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker
(/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands +=... yes
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker
(/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared
libraries... yes
checking dynamic linker

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Jan Lehnardt


On Mar 1, 2012, at 19:18 , Stefan Kögl wrote:

 On Thu, Mar 1, 2012 at 4:52 PM, Jan Lehnardt j...@apache.org wrote:
 Can you tell us how you installed 1.2.x? Is it a fresh installation,
 did you do an in-place update from an earlier installation (earlier
 1.2.x or 1.1.x or 1.0.x?
 
 I first did a fresh install of 1.2.x using R15B. I then removed R15B,
 installed R14B04 (both from source), compiled 1.2.x with the patch I
 mentioned earlier, and did an in-place update.
 
 If this is a problem, I could remove CouchDB first and do a fresh
 install instead. What would be the preferred way to do a clean
 uninstall?

I don't want to claim that this is definitely the cause for your
problem, but it'd be great if you could do a clean, fresh, empty
install to make sure we can rule that out as :)

Cheers
Jan
-- 

 
 
 -- Stefan
 
 
 On Mar 1, 2012, at 12:17 , Stefan Kögl wrote:
 
 Hello,
 
 My experiments to replicate some live data / traffic to a CouchDB
 1.2.x (running the current 1.2.x branch + the patch from [1]) that
 sparked the indexing speed discussions, did also yield another
 (potential) problem. First sorry for not further reporting back any
 performance measurements, but I didn't yet find the time to run the
 tests on my machines.
 
 Anyway, I found the following stack traces in my log (after noticing
 that some requests failed and compaction of a view stopped)
 
 http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt
 
 The files starts at the first failed requests. Every request before
 that returned a positiv (ie 2xx) status code. The crash might have
 some natural reason (such as timeouts, lack of RAM, etc), but I'm
 not sure how to interpret Erlang stack traces. Can somebody point me
 in the right direction for diagnosing the problem?
 
 
 Thanks,
 
 -- Stefan
 
 
 [1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Stefan Kögl

On 03/01/2012 07:38 PM, Jan Lehnardt wrote:
 On Mar 1, 2012, at 19:18 , Stefan Kögl wrote:
 If this is a problem, I could remove CouchDB first and do a fresh
 install instead. What would be the preferred way to do a clean
 uninstall?
 
 I don't want to claim that this is definitely the cause for your
 problem, but it'd be great if you could do a clean, fresh, empty
 install to make sure we can rule that out as :)

I just did

/etc/init.d/couchdb stop
make uninstall
make install
# edit local.ini -- why does that get removed anyway?
/etc/init.d/couchdb start

Is that enough to count as a fresh install, or should I do anything
else? I'll continue monitoring the instance. Previously the error
happened after a few days, so I can't say yet if the re-install changed
anything.


-- Stefan

[jira] [Commented] (COUCHDB-1424) make check hangs when compiling with R15B

2012-03-01 Thread Jan Lehnardt (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/COUCHDB-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220267#comment-13220267
 ] 

Jan Lehnardt commented on COUCHDB-1424:
---

I did some more tests, running make check in R15B on Snow Leopard and it didn't 
hang. Since this ran in a VM as opposed to real hardware on my previous 
reports, I re-ran this on a Lion VM with R15B and got the hang.

Unless there's reports to the contrary, this would narrow the problem to 
R15B/Lion.

 make check hangs when compiling with R15B
 -

 Key: COUCHDB-1424
 URL: https://issues.apache.org/jira/browse/COUCHDB-1424
 Project: CouchDB
  Issue Type: Bug
  Components: Test Suite
Affects Versions: 1.2, 1.3
Reporter: Jan Lehnardt

 make check hangs when running under R15B. For me it is 160-vhosts.t where 
 execution stops, but if I recall correctly others have reported other tests. 
 The crux here is that running the tests individually succeeds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: git commit: fix build with custom path - close #COUCHDB-1426

2012-03-01 Thread Benoit Chesneau

On Thu, Mar 1, 2012 at 7:14 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
 A few hunks in here concern me:

 -    CPPFLAGS=$CPPFLAGS -I/opt/local/include/js
    CPPFLAGS=$CPPFLAGS -I/usr/local/include
 -    CPPFLAGS=$CPPFLAGS -I/usr/local/include/js
    CPPFLAGS=$CPPFLAGS -I/usr/include
 -    CPPFLAGS=$CPPFLAGS -I/usr/include/js

 I remember having to add some of these for extremely specific
 scenarios. Are we absolutely sure this isn't going to lead to a
 regression for some people?

It should be handled in the js tests part not here.



 +AC_MSG_RESULT(js flags $CPPFLAGS)
 +

 This syntax looks weird to me. Its probably right but does anyone know
 the rules on when strings need square brackets?

 +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
 +                   #include jsconfig.h
 +                   ]],
 +                   [[
 +                    #if JS_VERSION == 170
 +                    // Use spidermonkey 1.7.0
 +                    #else
 +                    # Not Spidermonkey 1.7.0
 +                    #endif
 +                    ]])],
 +                    [use_js170=yes],
 +                    [])

 Please don't invent a new indentation scheme for random hunks in a
 patch. Also, what's actually being tested here? I'm not seeing how
 this would fail unless we're depending on jsconfig.h only existing in
 1.7.0 builds, in which case a test compile is not the way to run this
 check.


I don't invent a new indentation scheme actually. I just use the
defult provided by vim.

What it test is getting the version ==  170. If it's not equal it
fails. It actually works as expected.

 Everything after that hunk looks quite weird to me. I'm fairly certain
 we just had a commit that fixes this issue. I don't remember the
 details off the top of my head but this is getting into the land of
 silly walks with all the bending over backwards to find SpiderMonkey.
 At a certain point we might want to just ixnay a lot of this and just
 guess at the most common cases and if we can't find a version then we
 should just add a configure option.


The thing is that the way versions are tested is actually wrong. We
don't assume there could be more than one version in the patch we are
looking and e don't assume that what we want actually is an inferior
version of mozilla 185.

Reproducing the steps I gave allows to reproduce that.



 On Wed, Feb 29, 2012 at 6:01 PM,  j...@apache.org wrote:
 Updated Branches:
  refs/heads/COUCHDB-1426 [created] 56a00ede8


 fix build with custom path - close #COUCHDB-1426

 This patch make sure that js libs and include given using the options
 --with-js-lib and --with-js-include are used in priority, ie before the
 detection of the version. Also if spidermonkey 1.7.0 is detected it
 removes useless tests.


 Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
 Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/56a00ede
 Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/56a00ede
 Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/56a00ede

 Branch: refs/heads/COUCHDB-1426
 Commit: 56a00ede8ab237fc3b2c1a3ea23a688e5aa997c0
 Parents: 766d461
 Author: benoitc beno...@apache.org
 Authored: Thu Mar 1 00:16:14 2012 +0100
 Committer: Jason Smith (air) j...@apache.org
 Committed: Wed Feb 29 23:59:55 2012 +

 --
  configure.ac |  128 +
  1 files changed, 80 insertions(+), 48 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/couchdb/blob/56a00ede/configure.ac
 --
 diff --git a/configure.ac b/configure.ac
 index 7ce4842..e526a18 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -137,13 +137,33 @@ AC_ARG_WITH([erlang], 
 [AC_HELP_STRING([--with-erlang=PATH],
  ])
  AC_SUBST(ERLANG_FLAGS)

 -PKG_CHECK_MODULES([JS], [mozjs185], [
 +AC_ARG_WITH([js-lib], [AC_HELP_STRING([--with-js-lib=PATH],
 +            [set PATH to the SpiderMonkey library directory])],
 +    [
 +    JS_LIB_DIR=$withval
 +    JS_LIBS=-L$JS_LIB_DIR
 +    AC_MSG_RESULT(yo $JS_LIBS)
 +], [
 +    PKG_CHECK_MODULES([JS], [mozjs185], [
     JS_LIB_DIR=$(${PKG_CONFIG} --variable=libdir mozjs185)
 +    ], [
 +        PKG_CHECK_MODULES([JS], [mozilla-js = 1.7], [
 +            JS_LIB_DIR=$(${PKG_CONFIG} --variable=sdkdir mozilla-js)/lib
 +        ], [
 +            JS_LIB_DIR=${libdir}
 +        ])
 +    ])
 +])
 +
 +
 +AC_ARG_WITH([js-include], [AC_HELP_STRING([--with-js-include=PATH],
 +    [set PATH to the SpiderMonkey include directory])], [
 +    JS_INCLUDE=$withval
 +    JS_CFLAGS=-I$JS_INCLUDE
  ], [
     PKG_CHECK_MODULES([JS], [mozilla-js = 1.7], [
 -        JS_LIB_DIR=$(${PKG_CONFIG} --variable=sdkdir mozilla-js)/lib
 +        JS_CFLAGS=$(${PKG_CONFIG} --variable=includedir mozilla-js)/lib
     ], [
 -        JS_LIB_DIR=${libdir}

[jira] [Updated] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Benoit Chesneau (Updated) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Benoit Chesneau updated COUCHDB-1426:
-

Attachment: 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch

new patch fixing the issue of filippe. Just tested and it should work as
expected.

@davisp About possible indentation issue, tell me the bible and I will apply
it.

error while building with 2 spidermonkey installed
--

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Paul Joseph Davis (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220392#comment-13220392
]

Paul Joseph Davis commented on COUCHDB-1426:

@benoit

How about we match the rest of the file for formatting? There are zero cases of
indentation matching the argument column. Fixed width indents are used
throughout and should be used here as well.

As to the actual test in that AC_COMPILE_IFELSE I finally realized that its
relying on an error being generated due to an invalid preprocessing
instruction. It would be better to use the error preprocessor directive there.

The more I think on this the less I think its fixing either issue directly. The
globally installed SM 1.8.5 should have put its headers into $PREFIX/js/ which
was being picked up by the three lines you removed that I explicitly added in
response to a different error report. Seeing as the header checks haven't
changed I'm still not convinced that this isn't introducing a regression for
some combination of headers installed.

On the other hand, there's also this large rearrangement to fix the detection
of SM170 which didn't have the anonymous function option. It sure does seem
like there's quite a bit of change for this.

IOW, this patch should be at least two patches. And I'm not convinced we should
even attempt at supporting building against multiple installed versions of a
library. Picking up headers from system directories is going to be a bitch
regardless and trying to teach configure.ac to do a dance itself into knots
figuring this out seems like a losing proposition.

error while building with 2 spidermonkey installed
--

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Benoit Chesneau (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220411#comment-13220411
]

Benoit Chesneau commented on COUCHDB-1426:
--

I don't see the interrest to specify a lib and include paths if they are not
handled in priority. This isn't common at all.

On the other hand, there's also this large rearrangement to fix the detection
of SM170 which didn't have the anonymous function option. It sure does seem
like there's quite a bit of change for this. Can you elaborate ?

The patch can't be really splitted since all this change is needed. I didn't
want at first introduce this detection, but the way the tests are done
currently mozjs185 will be always took in priotirty if it exists on the disk
even if another path to find js libs has been used. It's probably the same for
1.8.0 though it should be fixed too.

The other way may be having something like --with-js-version= and we test
against that. Though it's still unusual to not use paths defined by the user to
find the correct lib. I guess it will give some headache to maintainers on OS
when they will have to deal with xulrunner, js 1.8 ... and maybe old lib still
installed for old programs. I think the correct way is to discover the versions
in this order :

path given : we should find the version in this path. I think in this case we
should test 1.7.0 - 1.8.5

if lib or include is not given: 1.8.5 - 1.8.0 - ... 1.7.0

error while building with 2 spidermonkey installed
--

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Paul Joseph Davis (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220442#comment-13220442
]

Paul Joseph Davis commented on COUCHDB-1426:

I don't see the interrest to specify a lib and include paths if they are not
handled in priority.

These are there for people to specify extra search paths when the library is
not installed in the system wide search paths.

This isn't common at all.

I assume you mean uncommon, and I'm not sure which you're referring to. The
priority of handling extra paths?

If so, then I would disagree a bit in regards to include and link search paths.
The compiler already has a default set of paths that it searches and we're
trying to work around that to a certain extent. It doesn't help that
SpiderMonkey makes this harder than it has to be, but at a certain point that's
what we get for using a language that was designed to be used in a browser.

On the other hand, there's also this large rearrangement to fix the
detection of SM170 which didn't have the anonymous function option. It sure
does seem like there's quite a bit of change for this. Can you elaborate ?

This is a fairly large change and a lot of it seems unnecessary. There are
definitely things we should include. For instance, I like that you reordered
the pkg-config check after the command line args checks. But the whole
use_js170 flag stuff seems extremely brittle and adds a fair amount of
complexity. Unless I'm mistaken we should be able to fix the bug by just
reordering the tests so we find defualt = 17.0; check for 1.8.0 - 1.8.5 -
too_new_version

The patch can't be really splitted since all this change is needed.

Sure it can and if it can't then it just means that we've done it wrong. There
are two issues here:

1. Accidentally picking up a system wide SpiderMonkey
2. Checking for JS_ANON_FUNFIX in 1.7.0 which is a bug.

Item #2 should be simple enough to fix by changing the ordering when we test
for the version detection.

Item #1 OTOH is a bit of a pain. Its definitely possible to make this work, but
I'm not entirely convinced that this patch accomplishes anything more than
allowing 1.8.5 installed globally which is different than 1.7 installed
globally.

error while building with 2 spidermonkey installed
--

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

2012-03-01 Thread Filipe Manana (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220456#comment-13220456
]

Filipe Manana commented on COUCHDB-1426:

Thanks Benoit.

However even with the latest patch I get the same issue as with the first patch:

gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/snappy/google-snappy
-I/opt/local/include -I/usr/local/include -I/usr/include -g -Wall -Werror
-D_BSD_SOURCE -DXP_UNIX -I/Users/fdmanana/sm185/install/include -O2 -g -O2 -MT
couchjs-http.o -MD -MP -MF .deps/couchjs-http.Tpo -c -o couchjs-http.o `test -f
'couch_js/http.c' || echo './'`couch_js/http.c
couch_js/http.c:19:19: error: jsapi.h: No such file or directory
In file included from couch_js/http.c:21:

However, Randall's initial spidermonkey 1.8.5 commit works for me on Mac OS X:

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf

A few weeks ago I recall master worked for me on Linux with custom
--with-js-include and --with-js-lib configure flags.

error while building with 2 spidermonkey installed
--

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Nathan Vander Wilt

Was your server under heavy load? Did you end up with a bunch of zombie couchjs 
processes?

I'm a little worried I'm hopping in on something that might be a separate 
issue, but I was consistently getting nasty crashes the other day when doing a 
Blitz.io rush on a _list function, stacktraces similar to this but in my case 
the database became completely unresponsive.

Basically:
1. build-couchdb (1.1.1) on an EC2 t1.micro running Ubuntu
2. Add the '42' file at the path Blitz.io is looking for (a simple way to do 
this is what's held up filing JIRA ticket)
3. Run their default rush on a _list function (mine happened to do a fair 
amount of work, doing a Markdown conversion and Mustache templating)
4. Around about the 40 concurrent user mark, CouchDB dies a terrible horrible 
death with a bunch of zombie couchjs process, all those numbers in the logs and 
some traces like:

{pid,0.116.0},
{registered_name,[]},
{error_info,
 {exit,
  {noproc,
   {gen_server,call,
[couch_httpd_vhost,
 {match_vhost,
  {mochiweb_request,#Port0.1461,'GET',/,
   {1,0},
   {7,

[Tue, 28 Feb 2012 23:47:57 GMT] [error] [0.712.0] Uncaught error in HTTP 
request: {exit,
 {timeout,
  {gen_server,call,
   [couch_query_servers,
{get_proc,
 {doc,
  _design/glob,
  {65,


Does this sound related, or separate issue? (Either way, I'm hoping to get a 
cleaner set of logs to submit.)

thanks,
-natevw


On Mar 1, 2012, at 3:17 AM, Stefan Kögl wrote:
 Hello,
 
 My experiments to replicate some live data / traffic to a CouchDB
 1.2.x (running the current 1.2.x branch + the patch from [1]) that
 sparked the indexing speed discussions, did also yield another
 (potential) problem. First sorry for not further reporting back any
 performance measurements, but I didn't yet find the time to run the
 tests on my machines.
 
 Anyway, I found the following stack traces in my log (after noticing
 that some requests failed and compaction of a view stopped)
 
 http://skoegl.net/~stefan/tmp/couchdb-1.2.x-crash.txt
 
 The files starts at the first failed requests. Every request before
 that returned a positiv (ie 2xx) status code. The crash might have
 some natural reason (such as timeouts, lack of RAM, etc), but I'm
 not sure how to interpret Erlang stack traces. Can somebody point me
 in the right direction for diagnosing the problem?
 
 
 Thanks,
 
 -- Stefan
 
 
 [1] http://friendpaste.com/178nPFgfyyeGf2vtNRpL0w

Re: Crash of CouchDB 1.2.x

2012-03-01 Thread Stefan Kögl

Hi,

On Fri, Mar 2, 2012 at 4:33 AM, Nathan Vander Wilt
nate-li...@calftrail.com wrote:
 Was your server under heavy load? Did you end up with a bunch of zombie 
 couchjs processes?

The crash occured under load, but there are no zombies - at least not anymore.

If the crash happens again I'll try to inspect it more closely.


-- Stefan

Re: Experiments with Git

Crash of CouchDB 1.2.x

Guide Champagne Euvrard Garnier - Edition 2012

Re: Experiments with Git

Re: Crash of CouchDB 1.2.x

Re: git commit: fix build with custom path - close #COUCHDB-1426

Re: Please report your indexing speed

Re: Crash of CouchDB 1.2.x

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

Re: Crash of CouchDB 1.2.x

Re: Crash of CouchDB 1.2.x

[jira] [Commented] (COUCHDB-1424) make check hangs when compiling with R15B

Re: git commit: fix build with custom path - close #COUCHDB-1426

[jira] [Updated] (COUCHDB-1426) error while building with 2 spidermonkey installed

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

Re: Crash of CouchDB 1.2.x

Re: Crash of CouchDB 1.2.x

20 matches

Site Navigation

Mail list logo

Footer information