Re: Hash table iterators, and a call for help
On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Yes please! Though IIRC they are have different performance characteristics, which might make that challenging in some cases. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On Fri, Jul 24, 2015 at 12:15:22PM +0800, Philip Chee wrote: On 23/07/2015 14:40, Mike Hommey wrote: On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote: On 22/07/2015 05:54, J. Ryan Stinnett wrote: The DevTools team is planning to move our code out of /browser/devtools and /toolkit/devtools and into a new top level /devtools directory. The main goals of this are to reduce confusion for new DevTools contributors and help us better organize our work in the future. It will also aid future users of the code in understanding what pieces they need to include. There should be no impact to DevTools features shipped in different products: Firefox desktop will continue to be the only product that ships the DevTools front end, and all others will ship the DevTools server only. What is the utility of shipping the back end without the front end? Remote-debugging Thunderbird with the devtools in Firefox. Nice. Note that's not new. The backend has been in toolkit forever. Does this make it easier for non-firefox applications to ship the front end too? e.g. SeaMonkey. As a matter of fact, the move to a different directory may help with that, since it's going to be easier to add that directory to the build system of non-Firefox apps without having to deal with the browser/ directory. That said, the code is not chrome://browser/ independent, so while this will make it easier, it's barely a small step. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: File system provider API
I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas On Fri, Jul 24, 2015 at 1:13 AM, Kershaw Chang kech...@mozilla.com wrote: Hi all, Summary: File system provider API [1] is now supported by Google. This API allows developers to create apps that support virtual file systems and make files stored on these to be available by Device Storage API. Use case: One of the use cases is to let Firefox OS have the ability to access cloud storage. With this API, users who install the app can have the cloud storage seamlessly integrated into Firefox OS. Accessing files on cloud becomes as easy as accessing locally. Idea of implementation: The idl should be very similar to Google's [2]. We plan to have this available to certified apps only. This will be released to privileged app until we think the implementation is mature enough. Link to standard: No formal specifications found on w3c. This API is only supported by Chrome OS now. Platform coverage: Firefox OS only. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1187223 Estimated or target release: We are looking to have this completed by Dec. 2015. [1] https://developer.chrome.com/apps/fileSystemProvider [2] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/api/file_system_provider.idl Thanks, Kershaw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: File system provider API
Hi all, Summary: File system provider API [1] is now supported by Google. This API allows developers to create apps that support virtual file systems and make files stored on these to be available by Device Storage API. Use case: One of the use cases is to let Firefox OS have the ability to access cloud storage. With this API, users who install the app can have the cloud storage seamlessly integrated into Firefox OS. Accessing files on cloud becomes as easy as accessing locally. Idea of implementation: The idl should be very similar to Google's [2]. We plan to have this available to certified apps only. This will be released to privileged app until we think the implementation is mature enough. Link to standard: No formal specifications found on w3c. This API is only supported by Chrome OS now. Platform coverage: Firefox OS only. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1187223 Estimated or target release: We are looking to have this completed by Dec. 2015. [1] https://developer.chrome.com/apps/fileSystemProvider [2] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/api/file_system_provider.idl Thanks, Kershaw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hash table iterators, and a call for help
On Fri, Jul 24, 2015 at 1:59 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Fri, Jul 24, 2015 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Yes please! Though IIRC they are have different performance characteristics, which might make that challenging in some cases. The only case I'm aware of where PLDHashTable is inferior is that it can be wasteful of space if individual elements are large, because you have all those empty entries. But that can be worked around by making elements have type |T*| instead of |T|. I thought that PLHashTable also allowed you to hold pointers to entries, whereas PLDHashTable move them around any time it rehashes. But I might misremember since in a quick skim of NodeInfoManager we don't seem to take advantage of anything like that. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hash table iterators, and a call for help
On Fri, Jul 24, 2015 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 23, 2015 at 10:16 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Yes please! Though IIRC they are have different performance characteristics, which might make that challenging in some cases. The only case I'm aware of where PLDHashTable is inferior is that it can be wasteful of space if individual elements are large, because you have all those empty entries. But that can be worked around by making elements have type |T*| instead of |T|. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: File system provider API
On 24/07/15 11:38, Jonas Sicking wrote: I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps? This strikes me as odd. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, XML Activity
On Thursday 2015-07-23 17:54 -0700, Jonas Sicking wrote: On Thu, Jul 23, 2015 at 3:43 PM, L. David Baron dba...@dbaron.org wrote: I'm not sure it's really a fight I want to take on right now, though. Trying to kill things at W3C has generally not seemed worth the effort to me. It's better to ignore it and let it die out by itself due to lack of attention. But being super clear that we don't plan to implement or review any aspects of this group sounds good to me. And leaving a comment that we'd prefer to see the WG closed also seems worth the effort. Chasing it beyond that does not. At least to me. I wrote the following abstention: # It's disappointing to see the W3C putting this much effort into XML work # that is not related to the needs of the Web. We don't support this # work, and would rather see the resources going into it going into things # that would help the Web, but it doesn't seem worth formally objecting to # it. # # I wouldn't expect to see any of the work of these groups being # implemented by Mozilla (or, I think, by any other browser vendors). # # It also seems particularly unfortunate to newly charter (XForms) or # recharter (EXI) working groups with such low activity levels as EXI and # XForms, neither of which appear to have much substantive activity on # their mailing lists. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, XML Activity
On Fri, Jul 24, 2015 at 2:23 PM, L. David Baron dba...@dbaron.org wrote: # It's disappointing to see the W3C putting this much effort into XML work # that is not related to the needs of the Web. We don't support this # work, and would rather see the resources going into it going into things # that would help the Web, but it doesn't seem worth formally objecting to # it. # # I wouldn't expect to see any of the work of these groups being # implemented by Mozilla (or, I think, by any other browser vendors). # # It also seems particularly unfortunate to newly charter (XForms) or # recharter (EXI) working groups with such low activity levels as EXI and # XForms, neither of which appear to have much substantive activity on # their mailing lists. Dbaron++ / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: File system provider API
On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 24/07/15 11:38, Jonas Sicking wrote: I think we should allow addons to implement something like this. But I don't think it's something that we should let apps do. / Jonas So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps? Yes. For FirefoxOS we're working on getting rid of installation for apps. Instead apps will be treated just like other web content that you simply browse to. In this model it doesn't make as much sense for apps to be changing the behavior of the user agent. Why would navigating to Dropbox and then navigating away from it suddenly change the behavior of your OS? How do you revert it? Instead we're going to use addons as the way that you customize your device. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozglue.dll crash
On 2015-07-24 7:37 AM, Meenakshi Shankar wrote: We are using Firefox SDKS for our FF extension (libs generated after compiling Firefox 40 beta 4 source using start-shell-msvc2013). As there are some differences between Firefox 39 and Firefox 40 binaries, instead of mozalloc.lib , the mozcrt.lib is used for building our binaries. Our extension is enabled. But While launching the browser we could see a crash at mozglue.dll when _AtlBaseModule.AddResourceInstance(...) code is called. Can someone kindly let us know if we need to make anyother changes withe respect to Firefox 40 sdks. I'm not sure if this is related but bug 858928 [1] slightly changed the order in which DLLs are loaded during startup. Check [2] for more details. Gabriele [1] Switch XRE_StartupTimelineRecord() from PRTime to mozilla::TimeStamp https://bugzilla.mozilla.org/show_bug.cgi?id=858928 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=858928#c12 signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: mozglue.dll crash
On 2015-07-24 7:37 AM, Meenakshi Shankar wrote: Hi, We are using Firefox SDKS for our FF extension (libs generated after compiling Firefox 40 beta 4 source using start-shell-msvc2013). As there are some differences between Firefox 39 and Firefox 40 binaries, instead of mozalloc.lib , the mozcrt.lib is used for building our binaries. Our extension is enabled. But While launching the browser we could see a crash at mozglue.dll when _AtlBaseModule.AddResourceInstance(...) code is called. Can someone kindly let us know if we need to make anyother changes withe respect to Firefox 40 sdks. Hi, Meenakshi - If you could direct this question to https://ask.mozilla.org/ it will a wider audience who may be able to help. Thanks, - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: New reftest analyzer keyboard shortcuts
Since keyboard shortcuts aren't very discoverable this is just a note to let you all know that in bug 1187025 I added some more keyboard shortcuts to the reftest analyzer. Previously '1' and '2' would switch between the test/reference images, and now 'd' will toggle the differences view and 'p' and 'n' will go to the previous/next result. Happy keyboarding! kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
mozglue.dll crash
Hi, We are using Firefox SDKS for our FF extension (libs generated after compiling Firefox 40 beta 4 source using start-shell-msvc2013). As there are some differences between Firefox 39 and Firefox 40 binaries, instead of mozalloc.lib , the mozcrt.lib is used for building our binaries. Our extension is enabled. But While launching the browser we could see a crash at mozglue.dll when _AtlBaseModule.AddResourceInstance(...) code is called. Can someone kindly let us know if we need to make anyother changes withe respect to Firefox 40 sdks. Regards, Meenakshi ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
