Re: Misplaced xpcomglue.lib
On Tuesday, 2 June 2015 02:17:09 UTC+5:30, Mike Hommey wrote: On Mon, Jun 01, 2015 at 12:51:23PM -0700, Meenakshi Shankar wrote: On Thursday, 28 May 2015 08:09:55 UTC+5:30, Mike Hommey wrote: On Wed, May 27, 2015 at 11:38:30AM -0700, Meenakshi Shankar wrote: Hi, We are using Firefox SDKS for our FF extension. The libs generated after compiling Firefox 39 beta 1 source (using start-shell-msvc2013) did not contain few libs (xpcomglue.lib,xpcomglue_s.lib,...) in the \mozilla-build\mozilla-beta\obj-i686-pc-mingw32\dist\lib folder, instead it was found at \mozilla-build\mozilla-beta\obj-i686-pc-mingw32\xpcom\glue\standalone. Can anyone kindly let us know, 1) If there is any change in FF 39 sdk build binaries Yes and no. There were changes that make libraries not installed to dist/lib anymore, but those never were the sdk libraries. The sdk libraries are in dist/sdk/lib. Mike Thanks Mike. After linking the xpcomglue_s.lib from the sdk path, below linker errors are seen 2xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2001: unresolved external symbol __imp__moz_free 2xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2001: unresolved external symbol __imp__moz_free 2xpcomglue_s.lib(Unified_cpp_xpcom_glue2.obj) : error LNK2001: unresolved external symbol __imp__moz_free See bug 1168291. Mike Thank you Mike. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com wrote: auto len = aArray.Length(); auto display = GetStyleDisplay()-mDisplay; It can save having to look up whether aArray.Length() returns size_t (I sure hope it does, though) or whether mDisplay is uint8_t or uint16_t. I have no sympathy for this. If you had a decent IDE, the IDE could do that lookup for you, but don't force the reader/reviewer of your code to do that. Code is read many more times than it is written. It also makes a lot of sense in situations where the type name is noise. e.g. auto foo = reinterpret_castReallyLongTypeName*(bar) auto it = map.find(stuff) This, on the other hand is a good reason. The first has the type name right there. The second has a type name that is clear from the type of the collection (and a really noisy name at that). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 06/02/2015 12:58 PM, smaug wrote: So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) One common auto usage I've seen is for storing the result of a static_cast. In this scenario, it lets you avoid repeating yourself and makes for more concise code. I don't think there's much danger of fragility in this scenario (unlike your refcounting example), nor is there any need for a reviewer/code-skimmer to do research to find out the type -- it's still right there in front of you. (it's just not repeated twice) For example: auto concretePtr = static_castReallyLongTypeName*(abstractPtr); Nice concise (particularly if the type name is namespaced or otherwise really long). Though it perhaps takes a little getting used to. (I agree that mixing auto with smart pointers sounds like a recipe for fragility disaster.) ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
Yeah, I like to ask myself whether I am losing any information by using auto. If it ends up eliminating redundancy within a line of code, I like to use it. OTOH if it eliminates useful human-friendly type information from the code then I don't. On 6/2/2015 2:43 PM, Martin Thomson wrote: On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com wrote: It also makes a lot of sense in situations where the type name is noise. e.g. auto foo = reinterpret_castReallyLongTypeName*(bar) auto it = map.find(stuff) This, on the other hand is a good reason. The first has the type name right there. The second has a type name that is clear from the type of the collection (and a really noisy name at that). ___ 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: Use of 'auto'
On 02/06/15 21:58, smaug wrote: Perhaps my mind is too much on reviewer's side, and less on the code writer's. I'd say it's the right place to put your mind. I always assume that code I review (and hopefully code I write) will be read by countless generations of contributors with much less experience than us and who will stumble upon every possible subtle error just because they don't know our codebase. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Tue, Jun 2, 2015 at 1:23 PM, L. David Baron dba...@dbaron.org wrote: On Tuesday 2015-06-02 22:58 +0300, smaug wrote: So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) One context where I think it often makes sense is for integral types, e.g., for things like: auto len = aArray.Length(); auto display = GetStyleDisplay()-mDisplay; It can save having to look up whether aArray.Length() returns size_t (I sure hope it does, though) or whether mDisplay is uint8_t or uint16_t. It also makes a lot of sense in situations where the type name is noise. e.g. auto foo = reinterpret_castReallyLongTypeName*(bar) auto it = map.find(stuff) - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Tuesday 2015-06-02 13:43 -0700, Martin Thomson wrote:
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey m...@kylehuey.com wrote:
auto len = aArray.Length();
auto display = GetStyleDisplay()-mDisplay;
It can save having to look up whether aArray.Length() returns size_t
(I sure hope it does, though) or whether mDisplay is uint8_t or
uint16_t.
I have no sympathy for this. If you had a decent IDE, the IDE could
do that lookup for you, but don't force the reader/reviewer of your
code to do that. Code is read many more times than it is written.
My assumption was that this would be for cases where neither the
reader nor writer is likely to care about which integral type it is,
and also cases that are near the threshold for whether to repeat (in
source code or perhaps only in execution) an expression or to put
the result of that expression in a variable.
For example:
auto display = mStyleDisplay-mDisplay;
if (frame-IsFrameOfType(nsIFrame::eLineParticipant) ||
nsStyleDisplay::IsRubyDisplayType(display) ||
mFrameType == NS_CSS_FRAME_TYPE_INTERNAL_TABLE ||
display == NS_STYLE_DISPLAY_TABLE ||
display == NS_STYLE_DISPLAY_TABLE_CAPTION ||
display == NS_STYLE_DISPLAY_INLINE_TABLE) {
... where most users would explicitly write mStyleDisplay-mDisplay,
but in this case it seems nicer to stick it in a variable than write
mStyleDisplay-mDisplay four times over.
Remember that if 'auto' is forbidden, people might get around it by
not using a variable at all (and instead repeating the expression)
rather than by writing the type explicitly on the variable... and
this doesn't provide type information. The cases I'm talking about
are ones where we're near the threshold between repeating the
expression or putting its value in a variable.
-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
Use of 'auto'
Hi all, there was some discussion in #developers about use of 'auto' earlier today. Some people seem to like it, and some, like I, don't. The reasons why I try to avoid using it and usually ask to replace it with the actual type when I'm reviewing a patch using it are: - It makes the code harder to read * one needs to explicitly check what kind of type is assigned to the variable to see how the variable is supposed to be used. Very important for example when dealing with refcounted objects, and even more important when dealing with raw pointers. - It makes the code possibly error prone if the type is later changed. * Say, you have a method nsRefPtrFoo Foo(); (I know, silly example, but you get the point) Now auto foo = Foo(); makes sure foo is kept alive. But then someone decides to change the return value to Foo*. Everything still compiles just fine, but use of foo becomes risky and may lead to UAF. Perhaps my mind is too much on reviewer's side, and less on the code writer's. So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron dba...@dbaron.org wrote:
My assumption was that this would be for cases where neither the
reader nor writer is likely to care about which integral type it is,
and also cases that are near the threshold for whether to repeat (in
source code or perhaps only in execution) an expression or to put
the result of that expression in a variable.
For example:
auto display = mStyleDisplay-mDisplay;
if (frame-IsFrameOfType(nsIFrame::eLineParticipant) ||
nsStyleDisplay::IsRubyDisplayType(display) ||
mFrameType == NS_CSS_FRAME_TYPE_INTERNAL_TABLE ||
display == NS_STYLE_DISPLAY_TABLE ||
display == NS_STYLE_DISPLAY_TABLE_CAPTION ||
display == NS_STYLE_DISPLAY_INLINE_TABLE) {
... where most users would explicitly write mStyleDisplay-mDisplay,
but in this case it seems nicer to stick it in a variable than write
mStyleDisplay-mDisplay four times over.
Remember that if 'auto' is forbidden, people might get around it by
not using a variable at all (and instead repeating the expression)
rather than by writing the type explicitly on the variable... and
this doesn't provide type information. The cases I'm talking about
are ones where we're near the threshold between repeating the
expression or putting its value in a variable.
Your full example is better. Context matters. And it highlights a
combination of other factors: the type of mDisplay is adequately
signaled by its usage (in this case), and the type of mDisplay might
reasonably be understood by the reader of the code. I initially
hadn't caught on that you were talking about CSS here, but it's
perhaps reasonable to expect that someone reading CSS code would know
what is used for something as fundamental as style.display.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 6/2/2015 2:58 PM, smaug wrote:
Hi all,
there was some discussion in #developers about use of 'auto' earlier
today.
Some people seem to like it, and some, like I, don't.
The reasons why I try to avoid using it and usually ask to replace it
with the actual type when I'm
reviewing a patch using it are:
- It makes the code harder to read
* one needs to explicitly check what kind of type is assigned to the
variable
to see how the variable is supposed to be used. Very important for
example
when dealing with refcounted objects, and even more important when
dealing with raw pointers.
- It makes the code possibly error prone if the type is later changed.
* Say, you have a method nsRefPtrFoo Foo(); (I know, silly
example, but you get the point)
Now auto foo = Foo(); makes sure foo is kept alive.
But then someone decides to change the return value to Foo*.
Everything still compiles just fine, but use of foo becomes risky
and may lead to UAF.
There are a few use cases for auto, in rough order that their utility is
most evident:
* auto x = []() {}; Lambdas don't even have a name that you can write down.
* STL iterator names, e.g., auto it = map.find(stuff); The type name is
simultaneously obvious and obnoxious.
* auto x = static_castFoo*(bar); You typed the name once, why should
you have to type it again.
* for (auto x : vec).
The case which I am personally very much on the fence is integral types.
On the one hand, sometimes the type just doesn't matter and you want to
make sure that you have the same type. On the other hand, I have been
very burned before by getting the signedness wrong and having code blow up.
I think that the first three cases are cases where auto not only should
be permitted but be required by the style guide; otherwise, I think auto
should be permitted (to reviewer/module owner's taste) but generally
strongly advised against. In particular, use of auto in lieu of things
like T* or nsRefPtrT should be forbidden except in special
circumstances (automatically-generated code being an example), where its
use would be carefully checked for correctness.
Just my opinion :-)
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Tuesday 2015-06-02 22:58 +0300, smaug wrote: So, I'd like to understand why people think 'auto' is a good thing to use. (bz mentioned it having some use inside bindings' codegenerator, and sure, I can see that being rather valid case.) One context where I think it often makes sense is for integral types, e.g., for things like: auto len = aArray.Length(); auto display = GetStyleDisplay()-mDisplay; It can save having to look up whether aArray.Length() returns size_t (I sure hope it does, though) or whether mDisplay is uint8_t or uint16_t. That said, I do agree that using auto often obscures information. -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: Linked Data and a new Browser API event
Gordan has the right general idea to approaching this problem space. On Mon, Jun 1, 2015 at 5:42 PM, Gordon Brander gbran...@mozilla.com wrote: On June 1, 2015 at 17:34:48 , Jonas Sicking (jo...@sicking.cc) wrote: I think we're already talking about reverse-engineering what search engines and twitter/facebook/etc do. The summary among all the myriad proprietary (read: single corp / oligopoly controlled) proposals is that Facebook OGP meta tags have a strong lead over all the other proprietary approaches (for various reasons we can get into offline if desired), while among the open standards community options - i.e. per Mozilla open web principles, microformats have the lead. But I'm still all for proper standardization. Including driving towards good technical solutions. Yup. We’re really talking about 2 things in parallel: 1. Defining a standards-based approach to marking these things up (using pre-existing patterns where it makes sense). Encouraging authors to use it. 2. Creating internal APIs that will leverage this metadata, and in cases where the standards-based metadata does not exist, scraping reasonable results from other common metadata or markup patterns. This analysis and conclusion matches what we've been figuring out with implementations and deployments in the IndieWebCamp community as well (which has several use-cases similar to pins/cards for providing summaries/link-previews of pages on the web). In short, the general approach involves parsing for two general sets of published data / markup: 1. Pragmatic parsing of what's most out there: a) according to anecdotal sampling by the indieweb community, Facebook OGP, and b) according to studies / open/common crawl datasets: classic microformats 2. Simplest open standards based approach (so we can recommend the easiest, least work, and most openly developed/maintained approach to authors and site owners) - microformats2. I'm happy to provide citations/specs for these, as well as follow-up on any detailed questions. Thanks, Tantek Çelik Web Standards Lead Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On 6/2/15 6:12 PM, Seth Fowler wrote: If you write this: auto val = Bar(); Foo(val); I think to preserve the semantics of Foo(Bar()) you need: auto val = Bar(); Foo(val); but apart from that nit, I totally agree. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is there any demo for Services.ww.getChromeForWindow
I am trying to use it and always return null. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of 'auto'
On Jun 2, 2015, at 1:59 PM, L. David Baron dba...@dbaron.org wrote: Remember that if 'auto' is forbidden, people might get around it by not using a variable at all (and instead repeating the expression) rather than by writing the type explicitly on the variable... and this doesn't provide type information. This is a point that’s worth calling out explicitly. When you write this: Foo(Bar()); You do not have to explicitly specify the return type of Bar(), and if you change both the return type of Bar() and the type of Foo()’s first parameter, you don’t have to update this callsite. If you write this: Baz val = Bar(); Foo(val); Now you’ve been forced to explicitly write out the return type of Bar(), and if you change the type of Foo() and Bar(), you have to update this call site as well. If you write this: auto val = Bar(); Foo(val); Then you’ve been able to pull the Bar() call into a separate statement without adding any additional coupling - you can change the type of Foo() and Bar() without updating this callsite, just as in the first case. An additional advantage of auto is that |val|’s type is actually the type that Bar() returns (modulo references and the like), which is _not_ guaranteed when you write out |val|’s type explicitly. If Bar()’s return type changes, but the new type has an implicit conversion to Baz, you may end up performing an conversion which you didn’t intend, and the compiler won’t catch it. This won’t happen with auto. I think there is definite value in auto’s reduced coupling and increased robustness to type changes in some cases. It can result in smaller patches which are easier to write, easier to review, bitrot less easily, and are easier to uplift, because fewer callsites need to be modified. Perhaps this will have no bearing on the final rules we adopt - I think generally the policy that auto should be used only when the code remains readable is something we can all agree on - but I wanted to explicitly call out some advantages of auto that I think are worth keeping in mind when deciding policy. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to inspect Js callstack from C++ callstack, I am using visual studio to debugging
Thanks for all, that's really helped!. 2015-06-02 20:47 GMT+08:00 Honza Bambas honzab@firemni.cz: invoke DumpJSStack() from the debugger. It will output to console or to the VC++ output window. -hb- On 6/1/2015 11:26, 罗勇刚(Yonggang Luo) wrote: mozjs.dll!js::jit::BaselineScript::icEntryFromPCOffset(unsigned int pcOffset) Line 553 C++ mozjs.dll!js::jit::DebugModeOSRVolatileStubjs::jit::ICCall_Fallback *::invalid() Line 56 C++ mozjs.dll!js::jit::DoGetElemFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICGetElem_Fallback * stub_, JS::HandleJS::Value lhs, JS::HandleJS::Value rhs, JS::MutableHandleJS::Value res) Line 4048 C++ [External Code] [Frames below may be incorrect and/or missing] mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData data) Line 126 C++ mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState state) Line 155 C++ mozjs.dll!js::RunScript(JSContext * cx, js::RunState state) Line 411 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 497 C++ mozjs.dll!js::Invoke(JSContext * cx, const JS::Value thisv, const JS::Value fval, unsigned int argc, const JS::Value * argv, JS::MutableHandleJS::Value rval) Line 531 C++ mozjs.dll!js::DirectProxyHandler::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 467 C++ mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::HandleJSObject * wrapper, const JS::CallArgs args) Line 465 C++ mozjs.dll!js::Proxy::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 2678 C++ mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 3082 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 468 C++ mozjs.dll!js::Invoke(JSContext * cx, const JS::Value thisv, const JS::Value fval, unsigned int argc, const JS::Value * argv, JS::MutableHandleJS::Value rval) Line 531 C++ mozjs.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandleJS::Value res) Line 8251 C++ [External Code] mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData data) Line 126 C++ mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState state) Line 155 C++ mozjs.dll!js::RunScript(JSContext * cx, js::RunState state) Line 411 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 497 C++ mozjs.dll!js::Invoke(JSContext * cx, const JS::Value thisv, const JS::Value fval, unsigned int argc, const JS::Value * argv, JS::MutableHandleJS::Value rval) Line 531 C++ mozjs.dll!js::DirectProxyHandler::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 467 C++ mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::HandleJSObject * wrapper, const JS::CallArgs args) Line 465 C++ mozjs.dll!js::Proxy::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 2678 C++ mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 3082 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 468 C++ mozjs.dll!js::Invoke(JSContext * cx, const JS::Value thisv, const JS::Value fval, unsigned int argc, const JS::Value * argv, JS::MutableHandleJS::Value rval) Line 531 C++ mozjs.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandleJS::Value res) Line 8251 C++ [External Code] mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData data) Line 126 C++ mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState state) Line 155 C++ mozjs.dll!js::RunScript(JSContext * cx, js::RunState state) Line 411 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 497 C++ mozjs.dll!js::Invoke(JSContext * cx, const JS::Value thisv, const JS::Value fval, unsigned int argc, const JS::Value * argv, JS::MutableHandleJS::Value rval) Line 531 C++ mozjs.dll!js::DirectProxyHandler::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 467 C++ mozjs.dll!js::CrossCompartmentWrapper::call(JSContext * cx, JS::HandleJSObject * wrapper, const JS::CallArgs args) Line 465 C++ mozjs.dll!js::Proxy::call(JSContext * cx, JS::HandleJSObject * proxy, const JS::CallArgs args) Line 2678 C++ mozjs.dll!js::proxy_Call(JSContext * cx, unsigned int argc, JS::Value * vp) Line 3082 C++ mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) Line 468 C++ mozjs.dll!Interpret(JSContext * cx, js::RunState state) Line 2620 C++
_stricmp exist in mozcrt.lib but stricmp doesn't exist.
It's the mozcrt.lib for vs 2010. Cause ms is automatcally relocate stricmp to _stricmp, but mozcrt.lib doesn't do that. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
