Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

L. David Baron wrote: > I'm not sure what the reason to prefer size_t/ptrdiff_t vs. > intptr_t/uintptr_t are (and I hope there aren't any cases where > they're different). I suppose size_t and ptrdiff_t have been around > longer, but intptr_t and uintptr_t have clearer names. But I also > tend to

Re: MDN Kuma wiki launch Friday at 10 AM PDT

On 8/3/12 8:45 PM, Justin Lebar wrote: If the plain-text syntax were tweaked to be more readable -- for example, by removing tags and replacing them with linebreaks, by removing redundant title attributes in tags, by rendering literal < and > characters inside instead of < and >, etc. -- then

Re: MDN Kuma wiki launch Friday at 10 AM PDT

I think I've done my side of the argument a disservice by focusing specifically on HTML as the enemy. There are all sorts of functions we could apply to the source code which would have exact inverses -- that is, you'd be able to edit the source in the Pretty Version and then translate it back los

Re: MDN Kuma wiki launch Friday at 10 AM PDT

On Sat, Aug 4, 2012 at 2:59 AM, Justin Lebar wrote: > Now, maybe your argument would be that everyone else should use the > rich text editor like you do, because it's an obviously-superior > experience. In that case, I'd suggest you just remove the ability to > edit the source directly, since th

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

2012/8/3 L. David Baron > I think there are also many cases where we should use either (size_t > and ptrdiff_t) or (intptr_t and uintptr_t), which are not int and > not explicitly sized. In some of these cases we use > PRUint32/PRInt32 today. I think we should be using these for things > that c

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

I think there are also many cases where we should use either (size_t and ptrdiff_t) or (intptr_t and uintptr_t), which are not int and not explicitly sized. In some of these cases we use PRUint32/PRInt32 today. I think we should be using these for things that correspond to the size or number of a

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

Benoit Jacob wrote: > Isn't that exactly what mfbt/StandardInteger.h does? Yes, but the question is now: are we going to switch to using them over PR* types? -- Blake Kaplan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.moz

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

2012/8/3 Chris Peterson > On 8/3/12 1:57 PM, Blake Kaplan wrote: > >> This is the second time this week that the prospect of replacing PRUintX >> in >> favor of stdint types has come up on this newsgroup. The JS engine already >> went through the pain of getting the include/type definition stuff

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On 8/3/12 1:57 PM, Blake Kaplan wrote: This is the second time this week that the prospect of replacing PRUintX in favor of stdint types has come up on this newsgroup. The JS engine already went through the pain of getting the include/type definition stuff right across the various platforms, so I

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

2012/8/3 Blake Kaplan > Justin Lebar wrote: > > tbsaunde pointed me to > > https://bugzilla.mozilla.org/show_bug.cgi?id=780203, where he's > > proposing we add stdint types to xpidl. I'd be happy to deprecate > > PRUintX in favor of stdint types. :) > > This is the second time this week that t

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

Justin Lebar wrote: > tbsaunde pointed me to > https://bugzilla.mozilla.org/show_bug.cgi?id=780203, where he's > proposing we add stdint types to xpidl. I'd be happy to deprecate > PRUintX in favor of stdint types. :) This is the second time this week that the prospect of replacing PRUintX in f

Re: MDN Kuma wiki launch Friday at 10 AM PDT

> Do you think that HTML is a good backing store for pages? No, because we can't losslessly translate from X markup language <--> HTML without X being as powerful as HTML. And that means that X inherits all of the ugliness of MDN's HTML markup. > If not, what should they be? We should store the

Re: MDN Kuma wiki launch Friday at 10 AM PDT

2012/8/3 Jeff Hammel > On 08/03/2012 11:38 AM, Benoit Jacob wrote: > > > > 2012/8/3 Jeff Hammel > >> I would argue HTML is a good, or even great, backing format. It's what >> mozilla does. It is a real standard. There are a plethora of tools to deal >> with HTML documents. It is very malleabl

Re: MDN Kuma wiki launch Friday at 10 AM PDT

On 08/03/2012 11:38 AM, Benoit Jacob wrote: 2012/8/3 Jeff Hammel mailto:jham...@mozilla.com>> I would argue HTML is a good, or even great, backing format. It's what mozilla does. It is a real standard. There are a plethora of tools to deal with HTML documents. It is very malleabl

Re: MDN Kuma wiki launch Friday at 10 AM PDT

Filed bugs: *Bug 780227* - MDN doesn't support wiki-style markup editing *Bug 780231* - MDN uses HTML as its source format, making interop with wiki markups hard (blocks 780227) Benoit

Re: MDN Kuma wiki launch Friday at 10 AM PDT

Replies inline. On 08/03/2012 07:59 AM, Justin Lebar wrote: While I personally don't understand some people's fascination with MediaWiki syntax (I can't stand it, myself), I know this is a Big Deal to some people. Let me try to help you understand. It's not an issue of being "fascinated" with

Re: MDN Kuma wiki launch Friday at 10 AM PDT

2012/8/3 Jeff Hammel > I would argue HTML is a good, or even great, backing format. It's what > mozilla does. It is a real standard. There are a plethora of tools to deal > with HTML documents. It is very malleable. There is a clear DOM > translation to its markup. How is this compatible wit

Re: MDN Kuma wiki launch Friday at 10 AM PDT

On 08/03/2012 07:46 AM, Benoit Jacob wrote: 2012/8/3 Sheppy On Friday, August 3, 2012 12:02:10 AM UTC-4, Benoit Jacob wrote: The #1 problem for many people with the current MDN wiki was that it didn't offer mediawiki-compatible markup editing. It would be great to be able to use right a

No Gfx meeting next week (August 6)

Hi, There won't be a gfx meeting next week. Reasons: - had one this week already - next monday (August 6) is a holiday in Gfxland^WCanada Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platfo

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

tbsaunde pointed me to https://bugzilla.mozilla.org/show_bug.cgi?id=780203, where he's proposing we add stdint types to xpidl. I'd be happy to deprecate PRUintX in favor of stdint types. :) On Fri, Aug 3, 2012 at 11:35 AM, Justin Lebar wrote: > Do we have a preference between using explicitly-s

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

> Are you just stating that it sucks as a type name because it's not clear? Yes. I guess, more than being unclear ("foo_t" would be unclear), it's downright misleading. On Fri, Aug 3, 2012 at 11:51 AM, Ted Mielczarek wrote: > On Fri, Aug 3, 2012 at 11:35 AM, Justin Lebar wrote: >> Do we have a

Re: Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

On Fri, Aug 3, 2012 at 11:35 AM, Justin Lebar wrote: > Do we have a preference between using explicitly-sized arguments (e.g. > PRInt32) and implicitly-sized arguments (e.g. long) in XPIDL? Is it really implicitly-sized? It's actually defined as PRInt32 by XPIDL. I agree that it sucks as a type n

Explicitly-sized arguments (e.g. PRInt32) versus implicitly-sized arguments (e.g. long) in IDL

Do we have a preference between using explicitly-sized arguments (e.g. PRInt32) and implicitly-sized arguments (e.g. long) in XPIDL? It seems to me that |long| is a particularly bad typename, because it means "32-bit integer" in IDL and means "64-bit integer" in C on many platforms. "long" also m

Re: XULRunner builds on Mac and Windows are currently broken

On Fri, Aug 03, 2012 at 04:12:30PM +0100, Neil wrote: > Ben Hearsum wrote: > > >Windows fails to compile: > >https://bugzilla.mozilla.org/show_bug.cgi?id=779910 > > > How do these builds differ from stock Firefox builds, is it just the > .mozconfig? --enable-application=xulrunner. That's about it

Re: XULRunner builds on Mac and Windows are currently broken

Ben Hearsum wrote: Windows fails to compile: https://bugzilla.mozilla.org/show_bug.cgi?id=779910 How do these builds differ from stock Firefox builds, is it just the .mozconfig? -- Warning: May contain traces of nuts. ___ dev-platform mailing lis

Re: HTTP-ON-EXAMINE-MERGED-RESPONSE

On Aug 2, 7:16 pm, Honza Bambas wrote: > On 8/2/2012 3:19 PM, Jan Honza Odvarko wrote: > > > > > > > > > According to the MDN here: > >https://developer.mozilla.org/en/Observer_Notifications#HTTP_requests > > > HTTP-ON-EXAMINE-MERGED-RESPONSE is: > > called *instead* of http-on-examine-response wh

Re: MDN Kuma wiki launch Friday at 10 AM PDT

> While I personally don't understand some people's fascination with MediaWiki > syntax (I can't stand it, myself), I know this is a Big Deal to some people. Let me try to help you understand. It's not an issue of being "fascinated" with MediaWiki syntax. (I think markdown would be even better

Re: MDN Kuma wiki launch Friday at 10 AM PDT

2012/8/3 Sheppy > On Friday, August 3, 2012 12:02:10 AM UTC-4, Benoit Jacob wrote: > > > > The #1 problem for many people with the current MDN wiki was that it > didn't > > offer mediawiki-compatible markup editing. It would be great to be able > to > > use right away one's familiarity with media

Re: MDN Kuma wiki launch Friday at 10 AM PDT

On Friday, August 3, 2012 12:02:10 AM UTC-4, Benoit Jacob wrote: > The #1 problem for many people with the current MDN wiki was that it didn't > offer mediawiki-compatible markup editing. It would be great to be able to > use right away one's familiarity with mediawiki markup (which is what most

Re: PGO and Windows

Jean-Marc Desperrier wrote: BTW the last time I had Seamonkey use all the 32-bits adress space, the result was *really* bad. A system down to it's knees, and not able to close the Seamonkey process anymore. It's harder to get the same thing with Firefox, the lazy tab opening helps :-) You ca

Re: GECKO 14: How to get thread safe object of nsIWebProgress

On Friday, August 3, 2012 3:45:59 PM UTC+5:30, salil...@gmail.com wrote: > On Wednesday, August 1, 2012 3:33:20 PM UTC+5:30, Neil wrote: > > sali...@gmail.com wrote: >My use case is, I have RPC listener in addon, which > is called from some other application. On receiving of RPC event, I need to

Re: GECKO 14: How to get thread safe object of nsIWebProgress

On Wednesday, August 1, 2012 3:33:20 PM UTC+5:30, Neil wrote: > sali...@gmail.com wrote: >My use case is, I have RPC listener in addon, which > is called from some other application. On receiving of RPC event, I need to > load a specific URL to the browser. For this I need nsIWebNavigation object