Re: #ifdefing out mailnews-only code but keeping it in m-c
On Mon, Nov 11, 2013 at 6:24 PM, Benjamin Smedberg wrote: > Why don't we remove them from core and let tbird devs deal with it when they > do have time (or stop supporting UTF7 and so forth if it's not important > enough to fix)? Removing the IMAP flavor of UTF-7 would break IMAP. I think it would be too hostile to break Thunderbird on that level and to require the Thunderbird developers to drop all other work to firefight such fundamental breakage. As for plain UTF-7 and the other encodings that are on track to becoming dead code in Firefox, if it happens to be the case that some of them are needed for email, it would be bad for Thunderbird if the lack of support slipped under the radar until release and problems only showed up with the wide audience of release builds. It would be less confrontational if a Thunderbird developer stepped up to implement https://bugzilla.mozilla.org/show_bug.cgi?id=937056 without the tree burning first. > FWIW, unless I don't understand how this uses the category manager, I doubt > that merging would be a problem, and this doesn't sound like a large task > for Thunderbird volunteers to take the code we're removing from m-c and port > it to c-c. Maybe it isn't a problem. I don't know how the category manager works, so I thought that it could potentially be a problem. >> By far the easiest solution would be leaving the code in m-c but >> #ifdefing it out of Firefox builds. Is there a compelling reason not >> to do so? If there is no compelling reason against #ifdefing it out in >> m-c, what's the right variable to #ifdef on (needs to work in >> moz.build and the preprecessor)? >> > I'm not certain whether tbird (and seamonkey) are currently using a shared > XULRunner in Linux distros. If they are, then this approach won't work well > (we'd at least have to continue disabling these encodings via prefs in > Firefox). I don't think that we should be doing the extra pain of ifdefs for > this case. What extra pain are you referring to? Sprinkling the #ifdefs around would be as easy as deleting the code from m-c. On Mon, Nov 11, 2013 at 7:14 PM, Gabriele Svelto wrote: > I did a quick check and found the following: > > - On Fedora the 'firefox' package depends on 'xulrunner' but not the > 'thunderbird' one > > - Similarly on Debian the 'iceweasel' package depends on 'xulrunner' but no > the 'icedove' one > > - On Gentoo neither the 'firefox' nor the 'thunderbird' package depend on > xulrunner as the 'xulrunner' package has been removed entirely I take this to mean that the set of decoders in XULRunner can match the set of decoders in Firefox. On Mon, Nov 11, 2013 at 8:33 PM, Joshua Cranmer 🐧 wrote: > Let me make a few things clear. First, as far as I know, no one cares about > UTF-7. That can probably be removed with no harm done to anyone. Someone cared the last time round when UTF-7 was removed from Thunderbird as a side effect of Firefox changes: https://bugzilla.mozilla.org/show_bug.cgi?id=677111 > The impact of other charsets are unknown. It is my belief that they could be > removed from Thunderbird with little or no wider impact. Unfortunately, I do > not have solid data to back this claim up. The reality of Thunderbird > development is such that, if this belief does not in fact ring true, we > would not find out until the next ESR version is released. The only way to > surely get this feedback faster is to add telemetry probes to the current > ESR branch and see which encodings are being used. Should one expect release management to allow https://bugzilla.mozilla.org/show_bug.cgi?id=935453 to be uplifted to ESR? (It would be nice to be able to uplift it to Aurora and Beta, too, to get data earlier.) On Mon, Nov 11, 2013 at 10:08 PM, Andrew Sutherland wrote: > On 11/11/2013 01:33 PM, Joshua Cranmer 🐧 wrote: >> Actually, I believe you need to keep the x-imap4-modified-utf7 converters >> in B2G, if you don't want to break Gaia Email's tests. They use the >> fakeservers as well, which specifically use this charset. > > This is minor/easy breakage for us to fix. I wouldn't keep the code around > for that reason. Do you mean it's something you'd fix reactively or is there something that needs to be handled proactively before x-imap4-modified-utf7 goes away from B2G? On Tue, Nov 12, 2013 at 1:57 AM, Mike Hommey wrote: > Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it > be possible to move those bits to c-c and do the same? It would be technically possible, sure. It would be more work than sprinkling #ifdefs in m-c. Maybe not much more work. I haven't done that sort of work before, so I wouldn't know how much extra work compared to #ifdefing it would be without doing the work. -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Booting to the Web
Hi, As far as I remember, thread scheduling in Firefox OS is handled by the Linux kernel, so if you are looking for documentation, you should probably look in that direction. Cheers, David On 11/12/13 6:14 AM, saurabhlnt...@gmail.com wrote: > Hi.. > I am presenting on the topic Firefox OS. I need your help to develope some > slides for "Thread Scheduling"in firefox OS. I am not able to find out any > data regrading thread scheduling. Kindly help. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Booting to the Web
Hi, There is nothing special about FFOS thread scheduling that I'm aware of. Threads are implemented by the underlying Linux kernel and are scheduled by the kernel itself. We use an Android kernel, so thread scheduling on FFOS is affected by wake locks. I don't know if we use cgroups* or nice levels for fine-tuning scheduling behavior. We don't have RT scheduling, etc. The b2g process, which is our main executable, contains a main thread that is always ready for running (i.e., it's guaranteed to make forward progress). And b2g uses a number of threads for off-loading long-running tasks. These threads are scheduled when there is work for them to do, but might also sleep; it depends on the thread's purpose. Best regards Thomas * /sys/fs/cgroup is empty, so probably not On 12.11.2013 06:14, saurabhlnt...@gmail.com wrote: > Hi.. > I am presenting on the topic Firefox OS. I need your help to develope some > slides for "Thread Scheduling"in firefox OS. I am not able to find out any > data regrading thread scheduling. Kindly help. > ___ > 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
Re: Booting to the Web
Hi John, I am presenting on the topic Firefox OS. I need your help to develope some slides for "Thread Scheduling"in firefox OS. I am not able to find out any data regrading thread scheduling. Kindly help. as Thomas already mentioned FxOS uses the regular Linux scheduler for handling threads; this includes the main thread of each application as well as DOM workers and other helper threads. Currently we adjust nice values to prioritize process and thread execution. Depending on the status of a process we assign it a different nice level. We've currently got 7 levels: MASTER - nice 0, used for the main b2g process FOREGROUND_HIGH - nice 0, used for processes holding a CPU wakelock FOREGROUND - nice 1, used for foreground processes FOREGROUND_KEYBOARD - nice 1, used for the keyboard app BACKGROUND_PERCEIVABLE - nice 7, used for background processes playing audio BACKGROUND_HOMESCREEN - nice 18, used for the homescreen app BACKGROUND - nice 18, used for all other background apps As you can see some levels share the same nice values, that's because those levels currently differ in the way they're treated by the out-of-memory killer. All those values can be adjusted at build time via preferences, you can find those here: http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/b2g/app/b2g.js#l610 Within a process the main thread receives the nice value of the process whilst DOM worker threads receive a nice value that is one point higher than the main thread (thus they run at a lower priority than the main thread). If you're interested how process priorities are handled you can find the relevant code here: http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/hal/HalTypes.h#l79 http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/dom/ipc/ProcessPriorityManager.h http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/dom/ipc/ProcessPriorityManager.cpp We don't use cgroups as Thomas mentioned because we found them to be hopelessly broken on certain kernels and we couldn't rely on them for a solid implementation. Being one of the persons who wrote this code I should really be doing a write-up of this in our Firefox OS architecture page but I didn't have enough time for it yet :-| Gabriele ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: The profiling branch has shut down
That's correct. It means that benchmarking on nighties isn't really accurate so beware when running web/js benchmarks. Also it is wrong to assume an average performance cost and scale the nightly results by a factor. We made this decision with the hope that we could better gather performance data that would in the end translate to shipping performance improvements to release users faster. This come as a slight cost to Nightly users. On Sun, Nov 10, 2013 at 6:01 PM, Ehsan Akhgari wrote: > On 2013-11-09 6:30 PM, Boris Zbarsky wrote: > >> On 11/9/13 12:53 PM, Philip Chee wrote: >> >>> Not directly related but. Some time back I wanted to turn on profiling >>> for SeaMonkey on our trunk builds but was vetoed because turning on >>> profiling (I was told) causes a pref hit. >>> >> >> It does, but a pretty small one, and only on x86-32 (because there is >> one less register to work with). >> > > Also note that we only enable profiling by default on Nightly and not the > channels that matter to our users. But that does mean that performance > comparisons between Nightly and Aurora on Windows for example are not > possible unless you do your own non-profiling Nightly builds. > > Cheers, > Ehsan > > > ___ > 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
Re: Booting to the Web
On 11/12/2013 10:27 AM, Gabriele Svelto wrote: Being one of the persons who wrote this code I should really be doing a write-up of this in our Firefox OS architecture page but I didn't have enough time for it yet :-| I was actually thinking while reading your mail that it was a great write up and should be on the page. :-) I took the liberty of adding it here: https://wiki.mozilla.org/B2G/Architecture#Threading Hope you don't mind. Thanks! Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: #ifdefing out mailnews-only code but keeping it in m-c
Mike Hommey wrote: Thunderbird is already linking stuff in libxul from c-c. Why wouldn't it be possible to move those bits to c-c and do the same? It's compiling components using the internal API and linking them into libxul because originally the mailnews components didn't compile against the external API. (Nowadays it's possible to get Thunderbird-on-xulrunner mostly working; this is handy for contributors on underpowered PCs as it takes much less time to rebuild libmail.) If the "stuff" consists only of XPCOM components then it would make no difference to Thunderbird whether they were compiled under mailnews or not. I don't know whether the comm-central build system can link non-components into libxul. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
On 11/8/2013 1:33 AM, fma spew wrote: 3- We haven't found any indication of Mozilla about alternatives for these kind of plug-ins, meaning plug-ins that need access to, in this case, Windows stuff. Google has provided alternatives though. One alternative is a Firefox extension. Firefox extensions can access both native platform APIs and web content. In particular, extensions can use js-ctypes to call C/C++ code. We've also mentioned the possibility of bundling a traditional plugin with a Firefox extension to change the default click-to-play behavior: "If a plugin is installed bundled within a Firefox extension, the extention can enable the plugin by default (for all sites or for particular sites) via preferences/permissions. Because the user chose to install the addon, I see no problem with allowing this sort of default activating." -- https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
