Re: OS/2 still supported ?

Enrico Weigelt, metux IT consult wrote: On 25.07.2017 02:04, Kris Maglione wrote: The only remaining in-tree references to the XP_OS2 macros are in NSPR and NSS, which are technically separate projects, and have their own sets of supported platforms. In esr52 there's a bit more:

Re: Extensions and Gecko specific APIs

On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: >> Should we moz-prefix moz-specific extensions? > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case

Re: OS/2 still supported ?

On 7/25/2017 8:40 PM, Ralph Giles wrote: libvpx is maintained upstream and updated periodically, so there's no point making changes if they're not also accepted upstream. The remaining OS/2 users would definitely not appreciate a crusade to kill support for that platform in upstream projects

Re: OS/2 still supported ?

Tue, Jul 25, 2017 at 8:25 PM, Steve Wendt wrote: > Likewise for libvpx and libffi? > libvpx is maintained upstream and updated periodically, so there's no point making changes if they're not also accepted upstream. I don't know about libffi; our vendored copy is a minor

Re: OS/2 still supported ?

On Tue, Jul 25, 2017 at 11:25 PM, Steve Wendt wrote: > On 7/25/2017 7:28 AM, Jeff Muizelaar wrote: > The only remaining in-tree references to the XP_OS2 macros are in NSPR and NSS, which are technically separate projects, and have their own sets of supported

Re: OS/2 still supported ?

On 7/25/2017 7:28 AM, Jeff Muizelaar wrote: The only remaining in-tree references to the XP_OS2 macros are in NSPR and NSS, which are technically separate projects, and have their own sets of supported platforms. The cairo stuff is from an upstream project and not worth removing. Likewise

Re: OS/2 still supported ?

On 7/25/17 1:04 AM, Enrico Weigelt, metux IT consult wrote: On 25.07.2017 02:04, Kris Maglione wrote: The only remaining in-tree references to the XP_OS2 macros are in NSPR and NSS, which are technically separate projects, and have their own sets of supported platforms. In esr52 there's a

Re: OS/2 still supported ?

On 25.07.2017 14:28, Jeff Muizelaar wrote: The cairo stuff is from an upstream project and not worth removing. The bundled cairo pieces are quite far away from upstream and ancient. Perhaps we should kick out the bundled stuff and use the original package (from distro) instead. --mtx

Re: Correct format specifier for size_t

On 25.07.2017 21:34, Mike Hommey wrote: Why not just adding GNU-style printf()+friends to nspr (perhaps even w/ printk() extensions) and use that everywhere, instead of having special cases or complex for fmt string construction everywhere ? --mtx

Re: Extensions and Gecko specific APIs

Experience from Web content standards probably informs the situation here... On Wed, Jul 26, 2017 at 11:46 AM, Andrew Swan wrote: > For handling cross-platform versus Firefox-specific APIs, I don't think the > right outcome is perfectly clear. Of course we should learn from

Re: Extensions and Gecko specific APIs

On Wed, Jul 26, 2017 at 11:07 AM, wrote: > I think that such an API could be spec'd such that it is portable, with > the output being flexible enough that we can put Mozilla-specific > information in there. E.g.: A fixed API to get the data, and a minimal > structure for

Re: Extensions and Gecko specific APIs

I believe that Gabor's response to the original question nicely captures the thinking and plans of everybody working on WebExtensions day-to-day. The questions about formally defining a policy for what to expose to extensions and about how to (or if we should) distinguish Firefox-specific APIs

Re: Extensions and Gecko specific APIs

On Wednesday, July 26, 2017 at 8:21:23 AM UTC+12, Andrew Overholt wrote: > On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: > > > Should we moz-prefix moz-specific extensions? > > > We have been trying not to do that for Web-exposed APIs but maybe the > extensions case

Re: Correct format specifier for size_t

On Tue, Jul 25, 2017 at 08:13:17PM +0200, Honza Bambas wrote: > Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal > toolchain version on Win) supports %z modifier. Only VS2013 and down only > defines %I. Are you sure? Because that's not listed on MSDN:

Re: removing "the old way" of signing add-ons

Op 7/23/2017 om 2:12 AM schreef Andrew Swan: > On Fri, Jul 21, 2017 at 12:32 AM, Jörg Knobloch wrote: > >> Since you're saying that we're still using the old interface, in fact >> Andrew said: "old add-on install >> confirmation dialog, that dialog includes a note about the

Re: Extensions and Gecko specific APIs

On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote: > Should we moz-prefix moz-specific extensions? We have been trying not to do that for Web-exposed APIs but maybe the extensions case is different? https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles

Re: Extensions and Gecko specific APIs

Should we moz-prefix moz-specific extensions? On 25/07/17 20:45, Jet Villegas wrote: > Based on product plans I've heard, this sounds like the right approach. We > should try to limit the scope of such browser-specific APIs but it's likely > necessary in some cases (e.g., in the devtools.) > >

Re: Extensions and Gecko specific APIs

Based on product plans I've heard, this sounds like the right approach. We should try to limit the scope of such browser-specific APIs but it's likely necessary in some cases (e.g., in the devtools.) On Tue, Jul 25, 2017 at 2:44 AM, Gabor Krizsanits wrote: > In my mind

Re: Correct format specifier for size_t

I filed bug 1384233 for removing the header and unnecessary defines. On Tue, Jul 25, 2017 at 2:13 PM, Honza Bambas wrote: > Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal > toolchain version on Win) supports %z modifier. Only VS2013 and down only >

Re: Correct format specifier for size_t

Thanks! OTOH, I think we no longer need it. Since VS2015 (our minimal toolchain version on Win) supports %z modifier. Only VS2013 and down only defines %I. -hb- On 7/25/17 7:03 PM, Botond Ballo wrote: We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE" for this purpose.

Re: Correct format specifier for size_t

We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE" for this purpose. Cheers, Botond On Tue, Jul 25, 2017 at 12:43 PM, Honza Bambas wrote: > In light of using PRxx formatting macros from inttypes.h, what is the right > approach to printf size_t types (like

Correct format specifier for size_t

In light of using PRxx formatting macros from inttypes.h, what is the right approach to printf size_t types (like our nsTArray::Length()) ? Not sure if to use "%zu" directly. Thanks. -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: OS/2 still supported ?

On Tue, Jul 25, 2017 at 4:04 AM, Enrico Weigelt, metux IT consult wrote: > On 25.07.2017 02:04, Kris Maglione wrote: > >> The only remaining in-tree references to the XP_OS2 macros are in NSPR >> and NSS, which are technically separate projects, and have their own >> sets

Re: Extensions and Gecko specific APIs

In my mind at least the concept is to share the API across all browsers where we can, but WebExtensions should not be limited to APIs that are accepted and implemented by all browser vendors. Google extensions have some Google app specific API that we might never implement because of technical

Extensions and Gecko specific APIs

Hi all, recently in couple of bugs there has been requests to add Gecko specific APIs for extensions. It isn't clear to me why, and even less clear to me is what the plan is there. I thought WebExtensions should work in several browsers, but the more we add Gecko specific APIs, the less

Re: OS/2 still supported ?

On 25.07.2017 02:04, Kris Maglione wrote: The only remaining in-tree references to the XP_OS2 macros are in NSPR and NSS, which are technically separate projects, and have their own sets of supported platforms. In esr52 there's a bit more: gfx/2d/DrawTargetCairo.cpp

Re: Announcing MozillaBuild 3.0 Release

> This means some people on older hardware or OSes aren't able build Firefox, This currently means that about 50% of the current users are not being able to build in the future. With Win 7 and 8.1 market share together we are not speaking about Vista here. I am building in a vm anyway so can