[dev-servo] meeting notes (UTF8)

2014-07-07 Thread Robert O'Callahan
I'm excited about pushing UTF8 as far as possible! One thing not mentioned in the notes is that Spidermonkey is adding Latin-1 string support, so hopefully it will be pretty easy to avoid converting ASCII-only strings at WebIDL boundaries. It would certainly be ideal if Spidermonkey eventually sup

Re: [dev-servo] meeting notes (UTF8)

2014-07-07 Thread Boris Zbarsky
On 7/7/14, 10:01 PM, Robert O'Callahan wrote: One thing not mentioned in the notes is that Spidermonkey is adding Latin-1 string support, so hopefully it will be pretty easy to avoid converting ASCII-only strings at WebIDL boundaries. Note that they also are adding GC-unstable string chars, so

Re: [dev-servo] meeting notes (UTF8)

2014-07-07 Thread Cameron Zwarich
Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access going to be a real possibility in SpiderMonkey? It’s obviously possible to make random access work with an appropriate indexing data structure, but popular JS benchmarks are pretty sensitive to string performance. Camer

Re: [dev-servo] meeting notes (UTF8)

2014-07-07 Thread Nicholas Nethercote
On Mon, Jul 7, 2014 at 7:51 PM, Cameron Zwarich wrote: > Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access > going to be a real possibility in SpiderMonkey? It’s obviously possible to > make random access work with an appropriate indexing data structure, but > popular

Re: [dev-servo] meeting notes (UTF8)

2014-07-07 Thread Robert O'Callahan
On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich wrote: > Are UTF8-backed (as opposed to Latin1-backed) JS strings with random > access going to be a real possibility in SpiderMonkey? It’s obviously > possible to make random access work with an appropriate indexing data > structure, but popular JS

Re: [dev-servo] meeting notes (UTF8)

2014-07-08 Thread Luke Wagner
> > Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access > > going to be a real possibility in SpiderMonkey? It’s obviously possible to > > make random access work with an appropriate indexing data structure, but > > popular JS benchmarks are pretty sensitive to string perfor