For more evidence how this affects us see the libmozjs-dev
conflicts with firefox on Ubuntu from today.
Cheers
Jan
--
On 19 Nov 2009, at 18:35, Mikeal Rogers wrote:
The issue seems to be that some stuff was broken in Spidermonkey that didn't
effect Firefox or Thunderbird and the fixes for
On Tue, Nov 24, 2009 at 7:05 PM, Jan Lehnardt j...@apache.org wrote:
For more evidence how this affects us see the libmozjs-dev
conflicts with firefox on Ubuntu from today.
Cheers
Jan
--
I'm not sure the XULRunner vs. Firefox vs. libmozjs is really related
to release versions. I'd consider
On Thu, Nov 19, 2009 at 7:38 AM, Dirkjan Ochtman djc.ocht...@gmail.com wrote:
On Wed, Nov 18, 2009 at 18:58, Mikeal Rogers mikeal.rog...@gmail.com wrote:
CouchDB currently uses Spidermonkey 1.7 as it's javascript interpreter.
1.7 was released in 2007. 1.8.5 is the current version number used
On Thu, Nov 19, 2009 at 13:47, Paul Davis paul.joseph.da...@gmail.com wrote:
I think this is the bug we want:
https://bugzilla.mozilla.org/show_bug.cgi?id=479473 which was last
updated in May.
Most people are already on 1.8.1 libraries because packagers appear to
have started pulling it from
On 19 Nov 2009, at 13:52, Dirkjan Ochtman wrote:
On Thu, Nov 19, 2009 at 13:47, Paul Davis paul.joseph.da...@gmail.com wrote:
I think this is the bug we want:
https://bugzilla.mozilla.org/show_bug.cgi?id=479473 which was last
updated in May.
Most people are already on 1.8.1 libraries
The issue seems to be that some stuff was broken in Spidermonkey that didn't
effect Firefox or Thunderbird and the fixes for that stuff is still being
back ported.
http://code.google.com/p/js18/wiki/BugzillaStatus
-Mikeal
On Thu, Nov 19, 2009 at 6:08 AM, Jan Lehnardt j...@apache.org wrote:
CouchDB currently uses Spidermonkey 1.7 as it's javascript interpreter.
1.7 was released in 2007. 1.8.5 is the current version number used in trunk,
anything 1.8.1 should have tracing support and should be much improved in
terms of performance.
1.8.x also has a lot of new JavaScript features
On Wed, Nov 18, 2009 at 11:52 AM, Paul Davis
paul.joseph.da...@gmail.com wrote:
On Wed, Nov 18, 2009 at 12:58 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
CouchDB currently uses Spidermonkey 1.7 as it's javascript interpreter.
1.7 was released in 2007. 1.8.5 is the current version number
On Wed, Nov 18, 2009 at 4:01 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
Also, I'm hesitant to upgrade our minimum version requirement. The SM
release story is less than awesome. The only tarballs at [3] are for
1.7 and 1.8.0 which is a weird limbo version between 1.7 and 1.8.1.
Not to
It'd be happy to make the switch to the newer spidermonkey. I don't
think we need to sweat the 'undefined' handling details.
When we chose JavaScript, it was because it is ubiquitous and simple.
We've got some code that expects a particular handling of 'undefined',
but if the language is
On Wed, Nov 18, 2009 at 5:07 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
I've not heard of any other browser implementing a JSON parser yet,
but I haven't paid the most attention. Though, I'm not sure why its
important.
IE8 has native JSON support, as does Safari 4.0.3.
Louis
Does anyone know the status of native JSON support on other browsers,
and how 'undefined' is handled?
Everyone I'm aware of (IE Safari) that are doing nativeJSON are following
the ECMA standard which handles undefined the same way Mozilla nativeJSON
does.
-Mikeal
On Wed, Nov 18, 2009 at 6:34 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
The same could be said of your Python view server vs. what's in
couchdb-python though, right? Or what happens when we move to a Py3K
view server? Not to mention if that language is even available. Or if
we go back
I don't think it's necessary to couple the server and API this way.
Erlang views don't communicate over the standard view server protocol, and a
pure JavaScript CouchDB wouldn't use the view server protocol for JavaScript
views either.
Having a design document refer to an API (and possibly the
On Wed, Nov 18, 2009 at 4:25 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
I don't think it's necessary to couple the server and API this way.
Erlang views don't communicate over the standard view server protocol, and a
pure JavaScript CouchDB wouldn't use the view server protocol for
On 19/11/2009 10:34 AM, Mikeal Rogers wrote:
I've been thinking about this a lot lately. There seems to be a tangle of
different concerns at different layers.
The way I look at it is:
-There is a protocol (hopefully versioned someday) which you can use to
implement a view server.
- A view
If we don't require a certain feature set in javascript, like if we want to
go lowest common denominator and make sure views are usable even in a
pure-javascript CouchDB in Internet Explorer then it would be pertinent to
add some additional features to the default javascript view server API
On Wed, Nov 18, 2009 at 9:40 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
JSON is also a separate question:
I think it's a no-brainer to switch our JSON 'undefined' handling to
the JavaScript way, if we intend to eventually upgrade to modern
JavaScript engines. Is anyone up for patching
On Wed, Nov 18, 2009 at 9:59 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
If we don't require a certain feature set in javascript, like if we want to
go lowest common denominator and make sure views are usable even in a
pure-javascript CouchDB in Internet Explorer then it would be
Back to the multiple JS version question though, its not quite the
same thing. jQuery is there to gloss over differences in
implementation. It is *not* for differences in the language. For
example, jQuery can paper of the differences between event names but
it can't implement iterators.
On 19/11/2009 1:59 PM, Mikeal Rogers wrote:
If we don't require a certain feature set in javascript, like if
we want to
go lowest common denominator and make sure views are usable even
in a
pure-javascript CouchDB in Internet Explorer then it would be
21 matches
Mail list logo
