Re: Support for non-UTF-8 platform charset
On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: (2014/01/16 12:22), Zack Weinberg wrote: On 2013-11-26 5:40 AM, Neil wrote: Henri Sivonen wrote: On Windows, do we really need to pay homage to the pre-NT legacy when doing Save As? How about we just use UTF-8 for HTML Page, complete reserialization like on Mac? You'll need a BOM, of course. (MXR turns up so little that it makes me wonder non-UTF-8 support might have already gone away for practical purposes.) Gecko gets a little confused when you run Linux on a non-UTF8 file system, so I'd agree with this. FWIW some time later, I've seen both Linux and *BSD devs state that even if the user's locale uses a legacy encoding, all filesystem paths should still be treated as UTF-8. I don't know if my discovery below which seems to agree with what Zack found is relevant here or not. But here it goes. Seeing BOM in quoted Neil's post prompts me to write this. I think Neil referred to a BOM inside serialized HTML files--not in file system paths. I noticed that 64-bit DEBUG BUILD of TB seems to fail a conversion of native char string vs unicode near the beginning of its invocation. Specifically, iconv() failed each time (and to my chagrin, it did not seem to fail on a different 32-bit Debian GNU/Linux. Not sure why. Maybe the default locale that I used during installation of linux may be different. See below.) I noticed the error in |make mozmill| test suite log. When I installed Debian GNU/Linux 64-bit, I used Japanese locale : ja_JP.UTF-8 Since I refreshed source code of comm-central mid-December, valgrind run of TB also reports strange illegal read of 4 byte past allocated buffer in the code sequence that leads up to iconv() failure, so I inserted many printf to dump data to see what is going on. Seems like a bug. I found that TB generates during its execution UTF-8 file path name strings WITHOUT BOM and still contain supposedly a valid UTF8 path name. I'm pretty sure that file system paths on Linux are not supposed to contain a BOM. Besides, a UTF-8 BOM is three bytes and, therefore, doesn't explain an off-by-four error. This seems to confuse the code in TB itself and iconv fails. (And I think it is an expensive failure although |iconv| seems to be called only a few times during TB invocation.) Case in point. Linux GUI environment (or maybe it is common linux practice, I don't know) has a file called ~/.config/user-dirs.dirs under one's home directory (~). And this file contains the mapping of Desktop, Download, and host of other symbolic names used in popular Desktop environment into one's L10N name that is shown on the desktop, it seems: at least the file itself mentions this near its beginning. For example, in my |user-dirs.dirs| file, I have the following. Raw image: not sure how it will show up on people's screen. # This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line you're # interested in. All local changes will be retained on the next run # Format is XDG_xxx_DIR=$HOME/yyy, where yyy is a shell-escaped # homedir-relative path, or XDG_xxx_DIR=/yyy, where /yyy is an # absolute path. No other format is supported. # XDG_DESKTOP_DIR=$HOME/デスクトップ XDG_DOWNLOAD_DIR=$HOME/ダウンロード XDG_TEMPLATES_DIR=$HOME/テンプレート XDG_PUBLICSHARE_DIR=$HOME/公開 XDG_DOCUMENTS_DIR=$HOME/ドキュメント XDG_MUSIC_DIR=$HOME/音楽 XDG_PICTURES_DIR=$HOME/画像 XDG_VIDEOS_DIR=$HOME/ビデオ Output of hexdump -C user-dirs.dirs: 23 20 54 68 69 73 20 66 69 6c 65 20 69 73 20 77 |# This file is w| 0010 72 69 74 74 65 6e 20 62 79 20 78 64 67 2d 75 73 |ritten by xdg-us| 0020 65 72 2d 64 69 72 73 2d 75 70 64 61 74 65 0a 23 |er-dirs-update.#| 0030 20 49 66 20 79 6f 75 20 77 61 6e 74 20 74 6f 20 | If you want to | 0040 63 68 61 6e 67 65 20 6f 72 20 61 64 64 20 64 69 |change or add di| 0050 72 65 63 74 6f 72 69 65 73 2c 20 6a 75 73 74 20 |rectories, just | 0060 65 64 69 74 20 74 68 65 20 6c 69 6e 65 20 79 6f |edit the line yo| 0070 75 27 72 65 0a 23 20 69 6e 74 65 72 65 73 74 65 |u're.# intereste| 0080 64 20 69 6e 2e 20 41 6c 6c 20 6c 6f 63 61 6c 20 |d in. All local | 0090 63 68 61 6e 67 65 73 20 77 69 6c 6c 20 62 65 20 |changes will be | 00a0 72 65 74 61 69 6e 65 64 20 6f 6e 20 74 68 65 20 |retained on the | 00b0 6e 65 78 74 20 72 75 6e 0a 23 20 46 6f 72 6d 61 |next run.# Forma| 00c0 74 20 69 73 20 58 44 47 5f 78 78 78 5f 44 49 52 |t is XDG_xxx_DIR| 00d0 3d 22 24 48 4f 4d 45 2f 79 79 79 22 2c 20 77 68 |=$HOME/yyy, wh| 00e0 65 72 65 20 79 79 79 20 69 73 20 61 20 73 68 65 |ere yyy is a she| 00f0 6c 6c 2d 65 73 63 61 70 65 64 0a 23 20 68 6f 6d |ll-escaped.# hom| 0100 65 64 69 72 2d 72 65 6c 61 74 69 76 65 20 70 61 |edir-relative pa| 0110 74 68 2c 20 6f 72 20 58 44 47 5f 78 78 78 5f 44 |th, or
Re: Support for non-UTF-8 platform charset
On Fri, Jan 17, 2014 at 11:39 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: All this use of iconv is sad, yes. I wouldn't be opposed to dropping the iconv code paths and using the OS X / Android code (that assumes that operating system's file system APIs always take UTF-8) for all *nix platforms. Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=960957 -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Documenting common patterns that cause intermittent test failures
Hi! If you've recently fixed an intermittent test failure - please can you see if the cause was something that should be documented on the best practices guide: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges The page was last added to in 2011 - I'm keen to see us revive it - once up to date the sheriffs will be advocating making it recommended reading for engineer new-hires and reviewers. Rather than playing constant whac-a-mole with intermittent failures, we should prioritise preventing their introduction in the first place. I'm also optimistic that we can use that page as the basis for some one-off static analysis of our existing tests to find some quick wins for reducing our orange factor [1]. Many thanks! Ed [1] http://brasstacks.mozilla.com/orangefactor/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Support for non-UTF-8 platform charset
(Sorry for top-posting.) Dear Henri Sivonen, Thank you for lucid explanation. I am trying to understand the details and am pondering inserting a few more dumps to figure out the answers to your newly raised questions. I will report my finding RSN. Thank you again. Your comment clears up a lot of questions I had. PS: One thing is for sure. I checked the 32-bit version log. There was no mention of iconv() failure. So the failure of iconv() is a little mysterious still. So I am not ruling out the 64-bit library problem under Debian GNU/Linux. (Have to find out a valid test suite for this.) (2014/01/17 18:39), Henri Sivonen wrote: On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: (2014/01/16 12:22), Zack Weinberg wrote: On 2013-11-26 5:40 AM, Neil wrote: Henri Sivonen wrote: On Windows, do we really need to pay homage to the pre-NT legacy when doing Save As? How about we just use UTF-8 for HTML Page, complete reserialization like on Mac? You'll need a BOM, of course. (MXR turns up so little that it makes me wonder non-UTF-8 support might have already gone away for practical purposes.) Gecko gets a little confused when you run Linux on a non-UTF8 file system, so I'd agree with this. FWIW some time later, I've seen both Linux and *BSD devs state that even if the user's locale uses a legacy encoding, all filesystem paths should still be treated as UTF-8. I don't know if my discovery below which seems to agree with what Zack found is relevant here or not. But here it goes. Seeing BOM in quoted Neil's post prompts me to write this. I think Neil referred to a BOM inside serialized HTML files--not in file system paths. I noticed that 64-bit DEBUG BUILD of TB seems to fail a conversion of native char string vs unicode near the beginning of its invocation. Specifically, iconv() failed each time (and to my chagrin, it did not seem to fail on a different 32-bit Debian GNU/Linux. Not sure why. Maybe the default locale that I used during installation of linux may be different. See below.) I noticed the error in |make mozmill| test suite log. When I installed Debian GNU/Linux 64-bit, I used Japanese locale : ja_JP.UTF-8 Since I refreshed source code of comm-central mid-December, valgrind run of TB also reports strange illegal read of 4 byte past allocated buffer in the code sequence that leads up to iconv() failure, so I inserted many printf to dump data to see what is going on. Seems like a bug. I found that TB generates during its execution UTF-8 file path name strings WITHOUT BOM and still contain supposedly a valid UTF8 path name. I'm pretty sure that file system paths on Linux are not supposed to contain a BOM. Besides, a UTF-8 BOM is three bytes and, therefore, doesn't explain an off-by-four error. This seems to confuse the code in TB itself and iconv fails. (And I think it is an expensive failure although |iconv| seems to be called only a few times during TB invocation.) Case in point. Linux GUI environment (or maybe it is common linux practice, I don't know) has a file called ~/.config/user-dirs.dirs under one's home directory (~). And this file contains the mapping of Desktop, Download, and host of other symbolic names used in popular Desktop environment into one's L10N name that is shown on the desktop, it seems: at least the file itself mentions this near its beginning. For example, in my |user-dirs.dirs| file, I have the following. Raw image: not sure how it will show up on people's screen. # This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line you're # interested in. All local changes will be retained on the next run # Format is XDG_xxx_DIR=$HOME/yyy, where yyy is a shell-escaped # homedir-relative path, or XDG_xxx_DIR=/yyy, where /yyy is an # absolute path. No other format is supported. # XDG_DESKTOP_DIR=$HOME/デスクトップ XDG_DOWNLOAD_DIR=$HOME/ダウンロード XDG_TEMPLATES_DIR=$HOME/テンプレート XDG_PUBLICSHARE_DIR=$HOME/公開 XDG_DOCUMENTS_DIR=$HOME/ドキュメント XDG_MUSIC_DIR=$HOME/音楽 XDG_PICTURES_DIR=$HOME/画像 XDG_VIDEOS_DIR=$HOME/ビデオ Output of hexdump -C user-dirs.dirs: 23 20 54 68 69 73 20 66 69 6c 65 20 69 73 20 77 |# This file is w| 0010 72 69 74 74 65 6e 20 62 79 20 78 64 67 2d 75 73 |ritten by xdg-us| 0020 65 72 2d 64 69 72 73 2d 75 70 64 61 74 65 0a 23 |er-dirs-update.#| 0030 20 49 66 20 79 6f 75 20 77 61 6e 74 20 74 6f 20 | If you want to | 0040 63 68 61 6e 67 65 20 6f 72 20 61 64 64 20 64 69 |change or add di| 0050 72 65 63 74 6f 72 69 65 73 2c 20 6a 75 73 74 20 |rectories, just | 0060 65 64 69 74 20 74 68 65 20 6c 69 6e 65 20 79 6f |edit the line yo| 0070 75 27 72 65 0a 23 20 69 6e 74 65 72 65 73 74 65 |u're.# intereste| 0080 64 20 69 6e 2e 20 41 6c 6c 20 6c 6f 63 61 6c 20 |d in. All local | 0090 63 68 61 6e 67 65 73 20 77 69 6c 6c 20 62 65 20 |changes will be | 00a0 72 65 74 61 69 6e 65 64 20 6f 6e 20 74 68 65 20
Re: Support for non-UTF-8 platform charset
On 2014-01-17 4:39 AM, Henri Sivonen wrote: On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: I found that TB generates during its execution UTF-8 file path name strings WITHOUT BOM and still contain supposedly a valid UTF8 path name. I'm pretty sure that file system paths on Linux are not supposed to contain a BOM. I'm certain they MUST NOT contain a BOM (in the RFC sense). Including a BOM would break code all over the place that assumes that filesystem paths can be concatenated with strcat(), that a path is absolute if and only if path[0] == '/', etc. All this use of iconv is sad, yes. I wouldn't be opposed to dropping the iconv code paths and using the OS X / Android code (that assumes that operating system's file system APIs always take UTF-8) for all *nix platforms. I'm going to do a little more research -- if I remember correctly, the Python crew tried to do this in their 3.0 release and ran into some trouble with it, and they came up with a more robust solution later in the 3.x series. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
I don't use Terminals for programming, I have the space for 100 chars. I
also usually don't open more than one window at a time. I usually just
switch between files very quickly if I need to correlate something.
Everytime single time I create a patch that touches a lot of code Gecko, I
feel like 80 chars is just not enough. My experience is obviously kind of
skewed, because I mostly edit function definitions in away that makes them
longer, i.e. replace JS::Value with JS::HandleJS::Value. I feel like a
thousand times I just barely miss the 80 char limit and I have to start
wrapping some arguments around, which can be really annoying, because
suddenly you also have to move something else etc.
I don't really care about 2/4 spaces, I just press tab anyway.
On Fri, Jan 17, 2014 at 3:03 AM, gokoproj...@gmail.com wrote:
re 80char vs 100chars:
I am for 80 chars.
If the argument for expanding to 100 or more is that screen is getting
wider, then the benefit of wide screen is able to fit multiple terminals in
one window. For normal workflow, I'd split my windows into two or
terminals, depending on what I am doing, so I don't see any benefit for
increasing the limit.
re braces for single statement:
I am for always braces.
If multi-statement logical statement requires braces pair, why make
exception to the single logical branch?
if (...)
do_stuff
vs
if (...) {
do_stuff
}
and if I need to add more statements (like adding debug), I don't need to
go back and add { } again which can be as difficult as adding { } in the
first place (but that's a one-time cost). I am not sure why this is not a
problem... I know, it sounds lazy, but since we are mentioning
productivity
re 2 spaces vs 4 spaces:
I'd keep with two-space.
I come from Python world and after working on Firefox for a while I am
used to two-space instead of four-space in Firefox.
Does four-space increase productivity? My take on this is that not
necessarily and productivity depends on the tool the developer is using. If
you use vim you can set the tab indentation to four spaces. You can also
set language-specific indentation. I can't speak of other editors and IDEs
out there and we certainly can't make everyone happy.
Chromium has the following style guide:
Python code should follow PEP-8, except that Chromium uses two-space
indentation instead of four-space indentation, and it uses MixedCase for
method names and function names instead of lower_case_with_underscores
I am not saying we have to stick with two-space because Chromium uses
two-space since Linux kernel is 8-space, but two-space is not rare at all
(I am not sure Chromium's decision is influenced by people who started
Chrome in the first place, as they had/have been firefox contributors).
Finally, another thing to consider when we write a style checker is to
consider this way of wrapping lines:
const SOME_REGEX_CONSTANT = new RegExp(^(str1|str2 +
str3|str4);
const SOME_KEYWORD_TO_SET = hello world +
what is going on?
___
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
Recent and upcoming DXR changes
DXR's been taking patches at a healthy rate, both to the soon-to-land UI branch and directly to production. I wanted to give you an update on what we've grown since November—including some handy but subtle new features you might not have noticed—along with a preview of what's coming next: https://blog.mozilla.org/webdev/2014/01/16/dxr-gets-more-correct-less-case-sensitive/ Thanks again for all your feedback; it's been primary in determining the direction of the project. Cheers! Erik ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozillaBuild 1.9.0 test build up
Thanks, Ryan! Can this be moved to https://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe, which is currently pointed at 1.8? I was accidentally using the old version before bsmith told me I could save a lot of time by upgrading. It did save a lot of time, probably 25% :) Monica - Original Message - On 11/26/2013 11:04 AM, Ryan VanderMeulen wrote: I just uploaded a test build of MozillaBuild 1.9.0. Please try it out and provide feedback, especially with mozmake. http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup1.9.0pre.exe Notable changes in this build: * Better support for newer MSVC and Windows SDK versions * Updated Mercurial to version 2.8.0 * Added mozmake (GNU make 4.0 + custom patches) Please mark any mozmake bugs you come across as blocking bug 927213 and CC :glandium. Thanks! -Ryan I should also point out that the necessary patches have already landed on m-c so that mach will automatically use mozmake over pymake if available. So mozmake should just work if you use |mach build|. ___ 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
Ideas for making it easier and less error prone for Firefox OS partners to expose certified only APIs
(Follow-ups to dev.platform please) Our Firefox OS partners occasionally need to expose new APIs to Firefox OS devices for things such as testing and diagnostics purposes. We should try to make doing that easier and less error prone to ensure fewer ways of making mistakes which would lead to the API being exposed unintentionally where it was not meant to be exposed. I have filed bug 958667 and bug 961116 with two proposals to make it possible to express certified only APIs which are hidden behind a permission check in WebIDL. There is also the obvious task of documenting what the proper way of implementing a new certified-only API is, which I am planning to do once those two bugs land. Can anybody think of other similar techniques which we can adopt to improve our story here? Suggestions on WebIDL annotations, code changes, documentation, etc. are much appreciated! Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozillaBuild 1.9.0 test build up
We would need to do a 1.9.0 release. https://bugzilla.mozilla.org/showdependencytree.cgi?id=927213hide_resolved=1is what is blocking that from happening. Kevin Brosnan On Fri, Jan 17, 2014 at 12:06 PM, Monica Chew m...@mozilla.com wrote: Thanks, Ryan! Can this be moved to https://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe, which is currently pointed at 1.8? I was accidentally using the old version before bsmith told me I could save a lot of time by upgrading. It did save a lot of time, probably 25% :) Monica - Original Message - On 11/26/2013 11:04 AM, Ryan VanderMeulen wrote: I just uploaded a test build of MozillaBuild 1.9.0. Please try it out and provide feedback, especially with mozmake. http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup1.9.0pre.exe Notable changes in this build: * Better support for newer MSVC and Windows SDK versions * Updated Mercurial to version 2.8.0 * Added mozmake (GNU make 4.0 + custom patches) Please mark any mozmake bugs you come across as blocking bug 927213 and CC :glandium. Thanks! -Ryan I should also point out that the necessary patches have already landed on m-c so that mach will automatically use mozmake over pymake if available. So mozmake should just work if you use |mach build|. ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Exact rooting is now enabled on desktop
Exact stack rooting is now enabled by default on desktop builds of firefox. What this Means === SpiderMonkey will no longer scan the stack for live roots; you must now wrap all GC thing pointers that live on the stack across a GC in the JS::Rooted template for SpiderMonkey to see them. See the comments in js/public/RootingAPI.h and the guide on the developer wiki[1] for further details. All currently existing instances in the browser build have been updated; the hazard analysis build on TBPL, SM(Hf), will catch any future pushes that break this invariant. Why Do We Need This === Exact rooting is required for us to use GC algorithms that relocate objects in memory. It will allow us to implement compacting GC to save memory and generational GC to push our performance to the next level. Fixing SM(Hf) Failures == If you do happen to introduce a rooting issue, the SM(Hf) build will help you track it down and fix it. SM(Hf) runs on all pushes that feed into m-c and is available in the default set that is run on try. It is also available individually through the Try Chooser as browser rooting analysis (-p linux64-br-haz). Once the build is complete and has reported a failure, click on the |results| link in the lower right pane of tbpl, then click on hazards.txt.gz to get the list. Each hazard report includes the name of the problematic variable, the call that might GC, including the file and line number, and the live range of the unrooted variable in question. Please read the wiki guide[2] or ask in #jsapi if you have any questions. Thanks to everyone who helped the project get to this point! In the next few weeks we'll be getting the hazard analysis running on mobile and b2g and deploying exact rooting on our remaining platforms. Cheers, Terrence 1- https://developer.mozilla.org/en-US/docs/SpiderMonkey/GC_Rooting_Guide 2- https://wiki.mozilla.org/Javascript:SpiderMonkey:ExactStackRooting ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
Congratulations! This has been an epic journey :-). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
On 1/17/14 3:24 PM, Terrence Cole wrote: Exact stack rooting is now enabled by default on desktop builds of firefox. *standing ovation forever* -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
Chiming in a little late: On Jan 6, 2014, at 6:35 PM, Joshua Cranmer pidgeo...@gmail.com wrote: I find prefixing member variables with 'm' to be useful, although I dislike using it in POD-ish structs where all the members are public. Fully agreed, and IMO the style guide should be changed to include this. The use of 'a' for arguments is where I am least consistent, especially as I extremely dislike it being used for an outparam return value That also bothers me. I'd support adding an 'o' prefix for outparams. I've never found much use for the 's', 'g', and 'k' prefixes, although that may just as well be because I've never found much use for using those types of variables in the first place (or when I do, it's because I'm being dictated by other concerns instead, e.g., type traits-like coding or C++11 polyfilling). I don't see the use in distinguishing between 's' and 'g'. They're both potentially dangerous globally-shared data, and that's the most important information the reader should know. (Except if they're immutable, of course, but then presumably they'd have a 'k' prefix.) We could classify them both as 'g', but considering the number of bugs I've seen stemming from unprotected access to these kinds of variables, I would support a more verbose and distinctive prefix like 'unsafe'. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
On Jan 7, 2014, at 3:22 PM, Cameron McCormack c...@mcc.id.au wrote: Patrick McManus wrote: Typically I have to choose between 1] 80 columns 2] descriptive and non-abbreviated naming 3] displaying a logic block without scrolling to me, #1 is the least valuable. Thoroughly agree. I also agree with this. Perhaps a compromise might be that we should aim for 80 columns except for cases where this would hurt readability, but have a hard limit at 100 columns. Given how verbose C++ is, an 80 column limit (for me) often ends up hurting readability more than it helps. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozillaBuild 1.9.0 test build up
On Fri, Jan 17, 2014 at 01:20:50PM -0800, Kevin Brosnan wrote: We would need to do a 1.9.0 release. https://bugzilla.mozilla.org/showdependencytree.cgi?id=927213hide_resolved=1is what is blocking that from happening. I think you meant https://bugzilla.mozilla.org/showdependencytree.cgi?id=928594hide_resolved=1 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
On 01/17/2014 01:24 PM, Terrence Cole wrote: Exact stack rooting is now enabled by default on desktop builds of firefox. I've never heard of a major project escaping from conservative GC once it had entered that state of sin; nor have I heard of anyone implementing a moving collector after starting with a non-moving collector. So, doing *both* is impressive. I hope it pays off big! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is it possible to set time zone in xulrunner with JS
My app is based on XULRUNNER. I found when I fetch the current timestamp with Date.prototype.getTime, It seems give me the GMT time not the time of my time zone. But in firefox, there is no such a problem. I am confused that is there a way to set the time zone in xulrunner with JS. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
