support IE. After installing Firefox most test
cases pass! Thanks! Maybe a suggestion is to put "IE not supported" beside
Test Suite on Futon.
> Futon Test Suite failed on Windows 8 Consumer Preview
> -
>
>
could try that.
> Futon Test Suite failed on Windows 8 Consumer Preview
> -
>
> Key: COUCHDB-1457
> URL: https://issues.apache.org/jira/browse/COUCHDB-1457
> Project: Co
Futon Test Suite failed on Windows 8 Consumer Preview
-
Key: COUCHDB-1457
URL: https://issues.apache.org/jira/browse/COUCHDB-1457
Project: CouchDB
Issue Type: Bug
Components
Ah, you'd just embed the http-parser itself, reducing dependencies instead of
trading one for another. +1,
Adam
On Aug 15, 2011, at 10:41 AM, Paul Davis wrote:
> Not sure I follow what you mean there. When I mentioned node's HTTP
> parser, I meant, the parser [1]. I'd still have to write my ow
Not sure I follow what you mean there. When I mentioned node's HTTP
parser, I meant, the parser [1]. I'd still have to write my own C
adaptor for that to Spidermonkey objects. Not entirely certain on the
REPL bit, but couchjs was basically a hack on top of the Spidermonkey
js REPL so going back to
I thought about suggesting node's parser, especially since you'd get the REPL
for free. I think the downside is that there are roughly 300 versions of node
out there, and I'd hate for our tests to keep breaking because of node's
development pace. libcurl is nothing if not stable.
Adam
On Aug
On Aug 14, 2011, at 12:55 PM, Paul Davis wrote:
> My plan was to rewrite couch.js to use the new request/response
> classes internally and then when we need closer HTTP access we'd be
> able to have it. Same for T and Tequals. and what not. There is at
> least one test that we just can't make
My plan was to rewrite couch.js to use the new request/response
classes internally and then when we need closer HTTP access we'd be
able to have it. Same for T and Tequals. and what not. There is at
least one test that we just can't make work in our current couchjs
based test runner because it need
Paul,
This is interesting, and if you're willing to put together the new
infrastructure I can help with writing tests. I would suggest a more
incremental approach that's less of a rewrite (rewrites often just get you back
to 0 from a user's perspective).
The existing CouchDB JS object se
Here's a bit of a brain dump on the sort of environment I'd like to
see our CLI JS tests have. If anyone has any thoughts I'd like to hear
them. Otherwise I'll start hacking on this at some point over the
weekend.
https://gist.github.com/1142306
On Thu, Aug 11, 2011 at 11:46 PM, Paul Davis
wrote:
> Your points are definitely well taken, and these are the sorts of
> things we should be engineering for and around. But I'll bring the arc
> back to CouchDB. Our test suite has the specific purpose of asserting
> that CouchDB behaves the way we
>> The 'verify my install' on trunk strikes me as a bad idea. If someone
>> reports a bug and says that the verify passes, I'm always going to ask
>> them to run the test suite too.
>
> That is the intended way.
I agree with Jan on this one. Our test suite rarely finds a bug in the
wild compared t
On Thu, Aug 11, 2011 at 5:57 AM, Jason Smith wrote:
> On Thu, Aug 11, 2011 at 4:29 PM, Paul Davis
> wrote:
>> All very good except this one paragraph. The CouchDB definitely should
>> not be expected to run with an intermediary server. If an intermediary
>> is broken, its quite all right that we
On Aug 11, 2011, at 1:23 PM, Robert Newson wrote:
> Somewhat OT but you reminded me of something.
>
> The 'verify my install' on trunk strikes me as a bad idea. If someone
> reports a bug and says that the verify passes, I'm always going to ask
> them to run the test suite too.
That is the inte
Somewhat OT but you reminded me of something.
The 'verify my install' on trunk strikes me as a bad idea. If someone
reports a bug and says that the verify passes, I'm always going to ask
them to run the test suite too. It exists, it seems, because the test
suite is too slow. As Paul has noted, som
On Thu, Aug 11, 2011 at 4:29 PM, Paul Davis wrote:
> All very good except this one paragraph. The CouchDB definitely should
> not be expected to run with an intermediary server. If an intermediary
> is broken, its quite all right that we engineer paths around
> brokenness, but that's secondary by
On Thu, Aug 11, 2011 at 3:47 AM, Jason Smith wrote:
> On Thu, Aug 11, 2011 at 2:29 PM, Robert Newson wrote:
>> I wonder if we should add a custom request header like
>> X-CouchDB-NoCache which sets all the cachebusting headers (Expires in
>> the paste, etc) rather than that hack.
>
> There are se
On Thu, Aug 11, 2011 at 2:29 PM, Robert Newson wrote:
> I wonder if we should add a custom request header like
> X-CouchDB-NoCache which sets all the cachebusting headers (Expires in
> the paste, etc) rather than that hack.
There are several reasons for an invalid (cached) response.
* reverse-pr
Well, there are some cases where we need to work around browser (I
mean, IE) bugs. This mechanism would be generic, so folks stuck
supporting antique browsers have a way to fix themselves. For example,
caching /_session is apparently the cause of login problems on
antediluvian browsers.
B.
On 11
Seems like that'd just end up eating its way into the code base
special casing all the various places we set headers.
On the other hand if we had a command line test runner and could very
specifically set headers without the confounding effects of running in
a browser this wouldn't even be an issu
I wonder if we should add a custom request header like
X-CouchDB-NoCache which sets all the cachebusting headers (Expires in
the paste, etc) rather than that hack.
On 11 August 2011 02:15, Filipe David Manana wrote:
> On Wed, Aug 10, 2011 at 5:58 PM, Paul Davis
> wrote:
>>
>> Since no one seems
On Wed, Aug 10, 2011 at 5:58 PM, Paul Davis wrote:
>
> Since no one seems to have believed me I decided to take a closer look
I believe you, and in my machine, replication.js, takes about 120ms.
> at replication.js tests. And as I pointed out it was just polling a
> URL in a tight loop for 3s at
On 10 August 2011 09:48, Paul Davis wrote:
> On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber wrote:
>> On 10 August 2011 03:19, Paul Davis wrote:
>>
>>> Also, yes. I've finally become irritated enough with clearing the
>>> browser cache between every test that I feel its time to do something
>>
On Wed, Aug 10, 2011 at 12:49 AM, Paul Davis
wrote:
> On Tue, Aug 9, 2011 at 8:11 PM, Filipe David Manana
> wrote:
>> On Mon, Aug 8, 2011 at 11:43 PM, Paul Davis
>> wrote:
>>> The entire test suite takes about 4 minutes to run on a semi recent
>>> MBA. Most of the tests are fairly speedy, but
On Tue, Aug 9, 2011 at 8:11 PM, Filipe David Manana wrote:
> On Mon, Aug 8, 2011 at 11:43 PM, Paul Davis
> wrote:
>> The entire test suite takes about 4 minutes to run on a semi recent
>> MBA. Most of the tests are fairly speedy, but four of them stick out
>> quite drastically:
>>
>> delayed_com
On Tue, Aug 9, 2011 at 5:30 PM, Randall Leeds wrote:
> On Tue, Aug 9, 2011 at 14:48, Paul Davis wrote:
>
>> On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber wrote:
>> > On 10 August 2011 03:19, Paul Davis wrote:
>> >
>> >> Also, yes. I've finally become irritated enough with clearing the
>> >> b
On Mon, Aug 8, 2011 at 11:43 PM, Paul Davis wrote:
> The entire test suite takes about 4 minutes to run on a semi recent
> MBA. Most of the tests are fairly speedy, but four of them stick out
> quite drastically:
>
> delayed_commits: 15s
> design_docs: 25s
> replication: 90s
> replcaitor_db: 60s
On Aug 10, 2011, at 12:30 AM, Randall Leeds wrote:
> On Tue, Aug 9, 2011 at 14:48, Paul Davis wrote:
>
>> On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber wrote:
>>> On 10 August 2011 03:19, Paul Davis wrote:
>>>
Also, yes. I've finally become irritated enough with clearing the
brow
On Tue, Aug 9, 2011 at 14:48, Paul Davis wrote:
> On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber wrote:
> > On 10 August 2011 03:19, Paul Davis wrote:
> >
> >> Also, yes. I've finally become irritated enough with clearing the
> >> browser cache between every test that I feel its time to do som
On Tue, Aug 9, 2011 at 4:04 PM, Dave Cottlehuber wrote:
> On 10 August 2011 03:19, Paul Davis wrote:
>
>> Also, yes. I've finally become irritated enough with clearing the
>> browser cache between every test that I feel its time to do something
>> productive about it.
>>
>
> Use private mode /inc
On 10 August 2011 03:19, Paul Davis wrote:
> Also, yes. I've finally become irritated enough with clearing the
> browser cache between every test that I feel its time to do something
> productive about it.
>
Use private mode /incognito / pr0n mode & just start a new session. I
know thats not hel
On Tue, Aug 9, 2011 at 9:38 AM, Adam Kocoloski wrote:
> On Aug 9, 2011, at 4:48 AM, Paul Davis wrote:
>
>> On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
>> wrote:
Also, I've been thinking more and more about beefing up the JavaScript
test suite runner and moving more of our br
On Tue, Aug 9, 2011 at 4:11 AM, Jens Rantil wrote:
> Hi,
>
> Does JS engine come bundled with HTTP request implementation or is that
> browser specific? If they do, you could execute the browser tests by running
> them through a JavaScript engine directly? That way you can preserve the
> JavaSc
On Aug 9, 2011, at 4:48 AM, Paul Davis wrote:
> On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
> wrote:
>>>
>>>
>>> Also, I've been thinking more and more about beefing up the JavaScript
>>> test suite runner and moving more of our browser tests over to
>>> dedicated code in those tests. If anyo
Hi,
Does JS engine come bundled with HTTP request implementation or is that browser
specific? If they do, you could execute the browser tests by running them
through a JavaScript engine directly? That way you can preserve the JavaScript
code, still run the tests and skip your favorite browser.
On Tue, Aug 9, 2011 at 2:40 AM, Robert Dionne
wrote:
>>
>>
>> Also, I've been thinking more and more about beefing up the JavaScript
>> test suite runner and moving more of our browser tests over to
>> dedicated code in those tests. If anyone's interested in hacking on
>> some C and JavaScript aga
>
>
> Also, I've been thinking more and more about beefing up the JavaScript
> test suite runner and moving more of our browser tests over to
> dedicated code in those tests. If anyone's interested in hacking on
> some C and JavaScript against an HTTP API, let me know.
Paul,
Jan and I talked
I've been running the Futon test suite quite a bit lately and I've
noticed that they starting to take quite a bit longer again.
The entire test suite takes about 4 minutes to run on a semi recent
MBA. Most of the tests are fairly speedy, but four of them stick out
quite d
Smith.
> Replication of test results DB in Futon test suite is broken
>
>
> Key: COUCHDB-1157
> URL: https://issues.apache.org/jira/browse/COUCHDB-1157
> Project: CouchDB
>
applied to 1.0.x and 1.1.x as well -
simple fix.
Needs confirmation that the new URL is the correct one.
> Replication of test results DB in Futon test suite is broken
>
>
> Key: COUCHDB-1157
>
Replication of test results DB in Futon test suite is broken
Key: COUCHDB-1157
URL: https://issues.apache.org/jira/browse/COUCHDB-1157
Project: CouchDB
Issue Type: Bug
Hi Robert,
I committed that as part of r986710 as it also fixes
support for Safari 5. Thanks for the digging :)
Cheers
Jan
--
On 7 Aug 2010, at 14:36, Robert Newson wrote:
> All,
>
> I spent a few hours this morning trying to get the full test suite
> running on Chrome. I failed for interest
All,
I spent a few hours this morning trying to get the full test suite
running on Chrome. I failed for interesting reasons that I think are
worth sharing.
Exactly two tests fail, attachments.js and replication.js
attachments.js fails because of an unidentified Chrome parsing bug. If
you remove
43 matches
Mail list logo
