May I know what would be the svn repository branch version for this? On Thursday, March 27, 2014 5:40:56 AM UTC-7, Sven Panne wrote: > > With the Chrome 34 stable release not too far in the future and the branch > for 35 already looming, it is a good time to give a small overview of the > recent and upcoming v8 API changes: > > * In the 34 branch, we removed basically all previously deprecated > things to wipe the slate clean. > > * The following functions require an Isolate* as the first argument > now: ObjectTemplate::New, FunctionTemplate::New, Object::New, Integer::New, > Integer::NewUnsigned, String::Empty, HandleScope::NumberOfHandles. > > * A few tweaks were made to the CpuProfiler API, so the following > methods are gone/replaced by new counterparts: CpuProfile::GetUid, > CpuProfiler::GetProfileCount, CpuProfiler::GetCpuProfile, > CpuProfiler::DeleteAllCpuProfiles. > > * We totally removed AssertNoGCScope, it was not instantiable at all. > > * The ExternalArrayType enum gets more spec-conformant constant names, > but the previous ones are still available for some time to ease the > transition. > > * The (pre)compilation API will change a bit in the 35 branch, because > the previous one was too confusing: When you had a Script, it was totally > unclear if it was bound to a context or not. We now cleanly distinguish > these via Script (= context-bound) and ContextUnboundScript. You have to > use BindToCurrentContext to convert the latter into the former to run it. > The API in this area has a few more tweaks to prepare for better caching of > (pre)compilation results in the future. > > We will continue to improve the whole API, especially regarding the > confusing notions of "default Isolate" and "current Isolate". In the > future, as a rule of thumb, an embedder should be prepared to have an > explicit Isolate at hand when one is needed, and you have to care for the > creation/destruction of Isolates explicitly. Magically creating a VM > instance before main() and relying on thread-local storage all over the > place is a constant source of bugs and confusion. Making the VM lifetime > explicit and having no notion of TLS in v8 will greatly simplify and > robustify things. This is how it should have been done in the first place, > but given the complexity of our code and the code of our embedders, the > transition is not easy and will take some time. > > Furthermore, we will try to make the platform dependencies (like threading > etc.) more explicit. You can already see the first steps towards that goal > in the Platform class in v8-platform.h, but there is definitely more to > come. > > A constantly changing API is not nice for embedders, that's clear, but we > have to improve things somehow. We try to keep the pain for embedders as > low as possible, but if you have any problems or questions regarding how to > update your code to work with the new API, feel free to ask on v8-users. >
-- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
