Re: [b2g] [Mozlandia] Introdution to Project FoxEye in Portland Work Week.
Hi, there, Below link is the presentation file for the session Introdution to Project FoxEye. https://wiki.mozilla.org/File:Project_FoxEye_Portland_Work_Week.pdf Basically we can do some amazing features on camera/MediaStream and gallery/HTMLImageElement based on this project. For example, text recognition, video editor, augmented reality, image filter, face detection/recognition, camera HDR/panorama, any camera/webcam related creatives can be benefited from this project. I already did text recognition with WebCam on browser and face tracking on Flame and browser. Feel free to contact me, if you want to see a live demo. You can also see below link for more information. https://wiki.mozilla.org/Project_FoxEye Bug ID: https://bugzilla.mozilla.org/show_bug.cgi?id=1100203 https://bugzilla.mozilla.org/show_bug.cgi?id=1100203 Best Regards, CTai - 原始郵件 - 寄件者: Chia-Hung Tai c...@mozilla.com 收件者: dev-platform@lists.mozilla.org, dev-...@lists.mozilla.org 寄件備份: 2014 12 月 4 星期四 下午 12:47:20 主旨: [b2g] [Mozlandia] Introdution to Project FoxEye in Portland WorkWeek. Hi, there, I would like to held a session to introduce a new project, FoxEye. The goal of this project is trying to bring modern computer vision technologies to the Web. I would like to hear your valuable inputs. When: 3:00 PM, Thursday, 4-Dec-2014 Where: Salon D, Ball-room level, Marriott Water Front. Agenda: 1. Why 2. What 3. Some demos on flame and browser. 4. How 5. Real world use cases 6. Conclusion 7. QA You can see https://wiki.mozilla.org/Project_FoxEye for more information. Best regards, CTai ___ dev-b2g mailing list dev-...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params
On Dec 4, 2014, at 11:28 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think this would be a slight improvement but the place where I really want out-parameters to be visible is at the caller, not the callee. Agreed! The simplest way to achieve that in C++, though, is to use pointer arguments (so the ‘' operator will generally get used at the callsite). The problem is that since pointers are overloaded and have several other uses besides out-params, the intention isn’t clear at the method definition. (And for longer methods, it can even be unclear in the implementation code.) The ‘o’ prefix nicely complements the practice of using ‘’ at the callsite, so we get clarity at the caller and the callee. I think that the cost of introducing this convention and dealing with the inconsistency of it being incompletely applied across the codebase for the foreseeable future probably outweighs the benefits. Well, converting all existing code to use this convention overnight definitely wouldn’t be worth it. And just adding this to the style guide will give us very little benefit *right now*. But I think if we add this to the coding style guide and convert things gradually in a pragmatic fashion - when we write new code, when we touch old code that doesn’t use the convention, and perhaps when we encounter an unclear method definition in the course of our work - a year or two down the road it may be common enough that we get significant benefits from the change. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params
On Dec 4, 2014, at 11:02 AM, Eric Rescorla e...@rtfm.com wrote: In contrast, Seth's suggestion would be an extremely clear indication that a parameter is an outparam. Yes, and because it's just a convention and not compiler enforced it can also be wrong. I don’t know of any realistic, usable way we could enforce this via the compiler in C++, though. I agree that in theory the ‘o’ prefix could be wrong, but code review provides us some degree of protection against these kinds of issues, and I don’t think we should let the perfect be the enemy of the good here. (After all, in theory the ‘a’ prefix we use for indicating arguments could be wrong, but in practice I have never seen a problem with that.) - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params
On Fri, Dec 5, 2014 at 12:08 PM, Seth Fowler s...@mozilla.com wrote: Well, converting all existing code to use this convention overnight definitely wouldn’t be worth it. And just adding this to the style guide will give us very little benefit *right now*. But I think if we add this to the coding style guide and convert things gradually in a pragmatic fashion - when we write new code, when we touch old code that doesn’t use the convention, and perhaps when we encounter an unclear method definition in the course of our work - a year or two down the road it may be common enough that we get significant benefits from the change. The interregnum period creates confusion in the minds of developers, who for example may not know whether to use o per the style guide or a to be consistent with surrounding code. This is a cost. I think in the past we've underestimated the costs of incomplete transitions in coding style. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params
You sometimes see comments for this, e.g. int foo(int aX, /* out */ char* aS); If we recommended/required this, it might make the interregnum period problem smaller? Nick On Fri, Dec 5, 2014 at 1:31 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Dec 5, 2014 at 12:08 PM, Seth Fowler s...@mozilla.com wrote: Well, converting all existing code to use this convention overnight definitely wouldn’t be worth it. And just adding this to the style guide will give us very little benefit *right now*. But I think if we add this to the coding style guide and convert things gradually in a pragmatic fashion - when we write new code, when we touch old code that doesn’t use the convention, and perhaps when we encounter an unclear method definition in the course of our work - a year or two down the road it may be common enough that we get significant benefits from the change. The interregnum period creates confusion in the minds of developers, who for example may not know whether to use o per the style guide or a to be consistent with surrounding code. This is a cost. I think in the past we've underestimated the costs of incomplete transitions in coding style. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ 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: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params
In APZ code, we've been using the prefix 'aOut' for out-parameters. This keeps them consistent with the general rule of 'a' for arguments while identifying out-parameters with a convention. Cheers, Botond - Original Message - From: Nicholas Nethercote n.netherc...@gmail.com To: Robert O'Callahan rob...@ocallahan.org Cc: dev-platform dev-platform@lists.mozilla.org, Seth Fowler s...@mozilla.com Sent: Friday, December 5, 2014 5:10:09 PM Subject: Re: Proposal: Change the coding style guide to allow an 'o' prefix toindicate out-params You sometimes see comments for this, e.g. int foo(int aX, /* out */ char* aS); If we recommended/required this, it might make the interregnum period problem smaller? Nick On Fri, Dec 5, 2014 at 1:31 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Dec 5, 2014 at 12:08 PM, Seth Fowler s...@mozilla.com wrote: Well, converting all existing code to use this convention overnight definitely wouldn’t be worth it. And just adding this to the style guide will give us very little benefit *right now*. But I think if we add this to the coding style guide and convert things gradually in a pragmatic fashion - when we write new code, when we touch old code that doesn’t use the convention, and perhaps when we encounter an unclear method definition in the course of our work - a year or two down the road it may be common enough that we get significant benefits from the change. The interregnum period creates confusion in the minds of developers, who for example may not know whether to use o per the style guide or a to be consistent with surrounding code. This is a cost. I think in the past we've underestimated the costs of incomplete transitions in coding style. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ 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
Bug 639134 changed boolean browser.display.use_document_colors to tristate browser.display.document_color_use
I think the changes for this bug are sub-optimal. First: https://hg.mozilla.org/mozilla-central/rev/460d573b8822#l3.17 +!ENTITY allowPagesToUseColors.automatic.label Automatic +!ENTITY allowPagesToUseColors.always.labelAlways +!ENTITY allowPagesToUseColors.never.label Never It's never explained anywhere what Automatic does. I expect end users to start hitting support.mozilla.org on this when this goes to release. This can be mitigated by replacing Automatic with something more informative, understandable, clearer, and less beware of leopard. My second problem is that the new preference is a tri-state (int) preference. The use of multi-state preferences has not always been a happy story. See For example: Bug 1042135 - Change three-state DNT back to two state and update text. Bug 530209 - Improve search suggestions ui for locationbar prefs I suggest that unless there is a clear win for a multi-state preference in this particular instance, we should stick to something simpler. For example two boolean preferences. The original preference: browser.display.use_document_colors plus a new one: browser.display.use_document_colors.even_for_high_contrast_os_themes.do_what_I_say_dammit Also the use case for Bug 639134 was for Windows. Does this setting have the proper effect on Linux and OSX? Is this even needed on non-windows? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform