This morning I've been asked to do a review for bug 980027 [1] mostly
because I've been working actively on that code and I did some small
reviews in the past. Since the change was relatively large this time
I've asked the patch author to ask a review from a Hal peer in addition
to me which lead us
The next MemShrink meeting will be brought to you by purging IPC messages prior
to B2G process shutdown:
https://bugzilla.mozilla.org/show_bug.cgi?id=999351
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
Ah right, I had forgotten about those issues. That's in fact exactly the
code that Henri was looking at. XHR would perhaps be better than the XPCOM
IO if it works, but I don't think anyone's done that investigation.
Gavin
On Tue, Apr 29, 2014 at 11:22 AM, Nathan Froyd wrote:
> - Original M
- Original Message -
> The current best practice for file I/O in privileged JS is OS.File. It
> has mechanisms for doing encoding conversion and compressing data.
> That there is some b2g code using NetUtil/XPCOM instead is a bug, and
> probably was caused by the relevant code being written
The current best practice for file I/O in privileged JS is OS.File. It
has mechanisms for doing encoding conversion and compressing data.
That there is some b2g code using NetUtil/XPCOM instead is a bug, and
probably was caused by the relevant code being written prior to the
existence of OS.File (o
But I want to build firefox using intel compiler except webrtc, webrtc
using icl is not stable, so I want to use cl to build webrtc.
On Tue, Apr 29, 2014 at 11:05 PM, Joshua Cranmer 🐧 wrote:
> On 4/29/2014 8:34 AM, xunxun wrote:
>
>> Hi,
>>
>> I noticed that WebRTC's mozmake.py (
>> media/we
On 4/29/2014 8:34 AM, xunxun wrote:
Hi,
I noticed that WebRTC's mozmake.py (
media/webrtc/trunk/tools/gyp/pylib/gyp/generator/mozmake.py ) has been
removed since 29.0
In the past, I usually modify the mozmake.py like this for something to
do:
On 4/29/2014 10:51 AM, xunxun wrote:
> Thank you for the explanation.
>
> And do you know how to change CXX in gyp?
>
I don't think that's a thing we support, sorry.
-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla
Thank you for the explanation.
And do you know how to change CXX in gyp?
On Tue, Apr 29, 2014 at 10:29 PM, Ted Mielczarek wrote:
> On 4/29/2014 9:34 AM, xunxun wrote:
> > Hi,
> >
> >I noticed that WebRTC's mozmake.py (
> > media/webrtc/trunk/tools/gyp/pylib/gyp/generator/mozmake.py ) has b
On 4/29/2014 9:34 AM, xunxun wrote:
> Hi,
>
>I noticed that WebRTC's mozmake.py (
> media/webrtc/trunk/tools/gyp/pylib/gyp/generator/mozmake.py ) has been
> removed since 29.0
>
>In the past, I usually modify the mozmake.py like this for something to
> do:
>
Hi,
I noticed that WebRTC's mozmake.py (
media/webrtc/trunk/tools/gyp/pylib/gyp/generator/mozmake.py ) has been
removed since 29.0
In the past, I usually modify the mozmake.py like this for something to
do:
On Tue, Apr 29, 2014 at 12:12 PM, Henri Sivonen wrote:
> The Web API for doing I/O is XHR, which would also take care of
> encoding conversion.
So it turns out that NetUtil.readInputStreamToString() *could* perform
the encoding conversion, too. Yet, callers opt not to do so and
perform conversion
> The Web API for doing I/O is XHR, which would also take care of
> encoding conversion.
...and JSON parsing. I see hand-rolled JSON I/O using XPCOM in B2G .jsm files.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing
Our unit tests generally assume that all the XPCOM cruft that we have
exist. We run our usual test suite, including xpcshell tests, on B2G.
Some of the XPCOM cruft is dead code except for unit tests on B2G.
Should be stop building unit test-only XPCOM components on B2G?
For example, do we believe
I did a very quick inspection of some relatively recent code,
Webapps.jsm, to find out why even recent code isn't using the encoding
conversion facilities that the Web offers and is instead using XPCOM
facilities.
The quick answer seems to be that the reason for not using Web APIs
for encoding con
On Mon, Apr 28, 2014 at 5:23 PM, Ehsan Akhgari wrote:
> On 2014-04-28, 10:17 AM, Henri Sivonen wrote:
>>
>> On Mon, Apr 28, 2014 at 4:36 PM, Ehsan Akhgari
>> wrote:
>>>
>>> On 2014-04-28, 8:59 AM, Henri Sivonen wrote:
New question:
We have various scriptable nsIFoo stuff (e.g. nsIP
We have a bunch of places where JS code uses extremely old XPCOM
components to convert between UTF-16 JS strings and UTF-8 bytes.
Typically, code using the old XPCOM facilities represents byte buffers
as JavaScript strings where the upper half of each UTF-16 code unit is
a zeroed and the lower half
17 matches
Mail list logo
