Re: intent to implement Streams
In addition to what Ben said, you may enjoy the FAQ https://github.com/whatwg/streams/blob/master/FAQ.md, especially How do readable streams relate to observables or EventTarget? and How do readable streams related to async iterables? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Sat, Jun 20, 2015 at 3:27 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I also think automated tools probably won't get us meeting the style guide perfectly -- e.g. the aforementioned line-length wrapping, and can they ensure CamelCaps() function names and aFoo/mFoo/gFoo/sFoo variable naming? -- so even if we do step 2 we'll still need some style vigilance during reviews, and possibly some manual style fixes later. But that's ok, and it would still be a clear improvement over the current situation. Yeah, full automation of all style rules is impossible and a non-goal. 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: Revisiting modelines in source files
On Fri, Jun 19, 2015 at 8:27 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc g...@mozilla.com wrote: We can mass rewrite the tree. But unless the tools to keep things consistent are easy and painless to use, this will add chaos. Chaos? There are two distinct steps here. 1. Get the style mostly consistent (e.g. spacing/indentation/bracing that erahm mentioned). This is probably best done in chunks, e.g. a few directories at a time, rather than a single mass rewrite, just because chunks are easier to manage. 2. Introduce auto-formatting of some kind. Step 1 is a necessary pre-requisite of 2, but step 1 is useful even if 2 doesn't happen. I also think automated tools probably won't get us meeting the style guide perfectly -- e.g. the aforementioned line-length wrapping, and can they ensure CamelCaps() function names and aFoo/mFoo/gFoo/sFoo variable naming? -- so even if we do step 2 we'll still need some style vigilance during reviews, and possibly some manual style fixes later. But that's ok, and it would still be a clear improvement over the current situation. Yeah, I've reviewed a bunch of poiru's patches, and the situation in those files is much better now. Before you'd end up with weird half-styles, and it was hard to know what you style you should even use in any chunk of code. Now, it is at least mostly consistent. Certainly, automated tools enforcing the style would be a big improvment, but just having the style cleaned up is very nice. Nick ___ 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: Revisiting modelines in source files
Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc g...@mozilla.com wrote: We can mass rewrite the tree. But unless the tools to keep things consistent are easy and painless to use, this will add chaos. Chaos? There are two distinct steps here. 1. Get the style mostly consistent (e.g. spacing/indentation/bracing that erahm mentioned). This is probably best done in chunks, e.g. a few directories at a time, rather than a single mass rewrite, just because chunks are easier to manage. 2. Introduce auto-formatting of some kind. Step 1 is a necessary pre-requisite of 2, but step 1 is useful even if 2 doesn't happen. I also think automated tools probably won't get us meeting the style guide perfectly -- e.g. the aforementioned line-length wrapping, and can they ensure CamelCaps() function names and aFoo/mFoo/gFoo/sFoo variable naming? -- so even if we do step 2 we'll still need some style vigilance during reviews, and possibly some manual style fixes later. But that's ok, and it would still be a clear improvement over the current situation. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mercurial with bash prompt
The advanced prompt at http://sjl.bitbucket.org/hg-prompt/quickstart/ does cause quite a bit of lag before it shows anything. Here's what --profile gives me: https://pastebin.mozilla.org/8837461 One thing I'd like to add with prompt would be the current label (central/inbound/etc) provided by the firefoxtree extension. Any ideas how to do that? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On 2015-06-18 8:36 PM, Eric Rahm wrote: On Thursday, June 18, 2015 at 7:28:44 AM UTC-7, kgu...@mozilla.com wrote: // This is a comment that was previously just over the eighty // character // limit but got rewrapped by clang-format just blindly // inserting // linebreaks willy-nilly and requires manual fixup. I think this is an issue that should be fixed in clang-format. However, to work around this incrementally I have been manually rewrapping comment blocks in the APZ code if I'm touching them anyway. Can we sidestep this by punting on enforcing a line length restriction with clang-format? This is fertile soil for new contributors, and trivial to scan for if clang doesn't deal with it. Don't block on this. Either file bugs (all the files in this part of the tree, if you like) and mark them [good first bug] or msg me a DXR link. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
Hi, Over the past year, I have converted a few directories (xpcom/, docshell/, embedding/) to Gecko style using a patched Clang-Format and a few other tools. On 17 June 2015 at 18:57, Gregory Szorc g...@mozilla.com wrote: First thing is first: what are the blockers to mass rewriting mozilla-central with clang-format's output? Here are a few diffs after running Clang-Format on a few recently Gecko style-ified directories: With my patched Clang-Format: https://gist.github.com/poiru/d10dfa978f351f20e975 With upstream Clang-Format: https://gist.github.com/poiru/c7d1aaf9e83bb653dc37 The patched Clang-Format produces reasonably good output, although there are still a couple of blockers (e.g. BEGIN/END macro indentation and class base clause indentation). If we want to seriously do this (and I'm all for it), I can work on getting those blockers fixed and upstreaming my patches. Note that Clang-Format will still produce changes that are not strictly necessary, but that is mostly a one-time cost and something we should just live with anyway. Automatic formatting is worth it. On 17 June 2015 at 10:07, Gregory Szorc g...@mozilla.com wrote: If so, perhaps we can find time in Whistler next week to better integrate clang-format into the development workflow. I'd be more than happy to help. +1 for talking about this in Whistler. I actually think the workflow integration is a more important issue at our scale. If developers are to use Clang-Format, we need to ensure that they all use the same version (as different versions may produce slightly different output) and that they all remember to run it for each commit. I introduced Clang-Format at my last workplace and even with a small team we bumped into both of those issues frequently. Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On Thursday, June 18, 2015 at 8:36:09 PM UTC-4, Eric Rahm wrote: Can we sidestep this by punting on enforcing a line length restriction with clang-format? I think it would be reasonably uncontroversial to just do the following initially: - spacing - indentation - bracing If we can do just this, I'm all for it. I just did another test run of clang-formatting the APZ code and if I ignore the line-length stuff I don't see any issues (I only skimmed the results though). kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: clear cache
On 19/06/2015 17:15, Marcello Stanisci wrote: Additionally, launching FF with '-clearcaches' or by setting the environmental 'MOZ_CLEAR_CACHES' does not seems to give the desired effect. The switch you want is -purgecaches 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
Re: In http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/larch-win64/latest/
Please file bugs if you have issues. cc me (:paul). On Fri, Jun 19, 2015 at 7:24 AM, 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: The graphene-41.0a1.en-US.win64.zip Doesn't package with icu dlls -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Mercurial with bash prompt
Does anyone here who works on FF source use some bash prompt variation for mercurial? something like this: http://stevelosh.com/blog/2009/03/mercurial-bash-prompts/ I was wondering what you use since the method in this link is taking a lot of seconds to run on each prompt. Can you share your $PS1 ? Thanks, Amit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mercurial with bash prompt
I have the following:
hg_ps1() {
hg prompt {({bookmark})} 2 /dev/null
}
export PS1='... $(hg_ps1)\$ '
I do not get multiple second latency.
You should capture --profile output from your prompt command and see what's
taking so long. File a Mozilla bug against Developer Services ::
hg.mozilla.org (for lack of a better component) and we'll dig to the bottom
of it. See also
https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/issues.html
On Fri, Jun 19, 2015 at 8:01 AM, Amit Zur sendwithch...@gmail.com wrote:
Does anyone here who works on FF source use some bash prompt variation for
mercurial?
something like this:
http://stevelosh.com/blog/2009/03/mercurial-bash-prompts/
I was wondering what you use since the method in this link is taking a lot
of seconds to run on each prompt.
Can you share your $PS1 ?
Thanks,
Amit
___
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: Revisiting modelines in source files
On Fri, Jun 19, 2015 at 6:45 AM, Birunthan Mohanathas birunt...@mohanathas.com wrote: Hi, Over the past year, I have converted a few directories (xpcom/, docshell/, embedding/) to Gecko style using a patched Clang-Format and a few other tools. On 17 June 2015 at 18:57, Gregory Szorc g...@mozilla.com wrote: First thing is first: what are the blockers to mass rewriting mozilla-central with clang-format's output? Here are a few diffs after running Clang-Format on a few recently Gecko style-ified directories: With my patched Clang-Format: https://gist.github.com/poiru/d10dfa978f351f20e975 With upstream Clang-Format: https://gist.github.com/poiru/c7d1aaf9e83bb653dc37 The patched Clang-Format produces reasonably good output, although there are still a couple of blockers (e.g. BEGIN/END macro indentation and class base clause indentation). If we want to seriously do this (and I'm all for it), I can work on getting those blockers fixed and upstreaming my patches. Note that Clang-Format will still produce changes that are not strictly necessary, but that is mostly a one-time cost and something we should just live with anyway. Automatic formatting is worth it. On 17 June 2015 at 10:07, Gregory Szorc g...@mozilla.com wrote: If so, perhaps we can find time in Whistler next week to better integrate clang-format into the development workflow. I'd be more than happy to help. +1 for talking about this in Whistler. I actually think the workflow integration is a more important issue at our scale. If developers are to use Clang-Format, we need to ensure that they all use the same version (as different versions may produce slightly different output) and that they all remember to run it for each commit. I introduced Clang-Format at my last workplace and even with a small team we bumped into both of those issues frequently. Agreed that workflow is important. We can mass rewrite the tree. But unless the tools to keep things consistent are easy and painless to use, this will add chaos. Some ideas: * We can write commit hooks that will auto format code on local commit. * We can stand up a web service for auto formatting code. * We can track the blessed Clang version via an in-tree manifest and have a mechanism for ensuring the local version is up to date (tooltool or some such). * MozReview can reformat automatically during push/review time If someone commits to producing a suitable clang-format binary/config, I'll sign up for creating all the tooling. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to implement Streams
Also, I have setup a session on streams in the DOM room at Whistler: http://juneworkweekwhistler2015.sched.org/event/28ff926a768953ba39a44cd36598d7f7 Please stop by if you have questions or just want to talk about it. Thanks! Ben On Fri, Jun 19, 2015 at 2:00 PM, Benjamin Kelly bke...@mozilla.com wrote: Streams provide a JS primitive for accessing incremental, streamed data. For example, the fetch Response object can expose a body ReadableStream which allows reading a potentially infinite http response. Currently the only way to do something like this is with XMLHttpRequest with the append extension. Unfortunately that still requires keeping the entire resource in memory as data is appended. Streams do not have this limitation. Chrome has shipped the fetch Response.body stream, but not the rest of the API. I spent time evaluating this spec over the last few months. I put the findings from that eval in a blog post here: https://blog.wanderview.com/blog/2015/06/19/intent-to-implement-streams-in-firefox/ There were three main concerns for which I believe we now have consensus on how to move forward: 1) Possible performance issues with the async read() function. 2) Operating on public functions can preclude optimizations like off-main-thread copying of streams. 3) Streams need to support transfer between threads. These are discussed more fully in the blog post linked above. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1128959 Standard: https://streams.spec.whatwg.org/ Platforms: All ETA: Initial implementation of Response.body stream in by end of 2015. Full spec in first half 2016. Pref: TBD (depends on if DOM or jsapi self-hosted) devtools: TBD as its unclear what additional features devtools would need for Streams. Please let me know if there are any questions or concerns. Thank you! Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
intent to implement Streams
Streams provide a JS primitive for accessing incremental, streamed data. For example, the fetch Response object can expose a body ReadableStream which allows reading a potentially infinite http response. Currently the only way to do something like this is with XMLHttpRequest with the append extension. Unfortunately that still requires keeping the entire resource in memory as data is appended. Streams do not have this limitation. Chrome has shipped the fetch Response.body stream, but not the rest of the API. I spent time evaluating this spec over the last few months. I put the findings from that eval in a blog post here: https://blog.wanderview.com/blog/2015/06/19/intent-to-implement-streams-in-firefox/ There were three main concerns for which I believe we now have consensus on how to move forward: 1) Possible performance issues with the async read() function. 2) Operating on public functions can preclude optimizations like off-main-thread copying of streams. 3) Streams need to support transfer between threads. These are discussed more fully in the blog post linked above. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1128959 Standard: https://streams.spec.whatwg.org/ Platforms: All ETA: Initial implementation of Response.body stream in by end of 2015. Full spec in first half 2016. Pref: TBD (depends on if DOM or jsapi self-hosted) devtools: TBD as its unclear what additional features devtools would need for Streams. Please let me know if there are any questions or concerns. Thank you! Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to implement Streams
Out of curiosity: can these streams be used as a base for reactive programming? Or is it an entirely separate notion of streams? Cheers, David On 19/06/15 20:09, Benjamin Kelly wrote: Also, I have setup a session on streams in the DOM room at Whistler: http://juneworkweekwhistler2015.sched.org/event/28ff926a768953ba39a44cd36598d7f7 Please stop by if you have questions or just want to talk about it. Thanks! Ben -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
If someone commits to producing a suitable clang-format binary/config, I'll sign up for creating all the tooling. It looks like Birunthan stated he'd be willing to work on the clang-format side (I'm also happy to help out) if we are committed to integrating it into our wrorkflow. I found an older bug [1] that Anthony Jones filed to upstream some patches he was working on, although I think that attempt was abandoned. Perhaps we can revive that? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=961541 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to implement Streams
On Fri, Jun 19, 2015 at 2:46 PM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Out of curiosity: can these streams be used as a base for reactive
programming? Or is it an entirely separate notion of streams?
I'm not an expert on reactive programming, but I believe its based around
the observables pattern. Basically a way to signal next object, complete,
and error. I believe most APIs look something like:
function handleNext() { ... }
function handleComplete() { ... }
function handleError() { ... }
data.subscribe(handleNext, handleComplete, handleError);
The WhatWG Streams proposal is a superset of observables. You can achieve
the same sort of behavior by doing something like:
data.subscribe(new WritableStream({
write: handleNext,
close: handleComplete,
abort: handleError
}));
// data then uses WritableStream.write(), .close(), and .abort() to
communicate changes
You could also use ReadableStream, but it doesn't look as similar to
observables:
var reader = data.getStream().getReader();
reader.read().then(function handleRead(value) {
handleNext(value);
return reader.read().then(handleRead);
}).catch(handleError);
reader.closed.then(handleComplete);
I think the Streams spec is more comprehensive to just observables because
it offers a pull interface in ReadableStream instead of just a push
interface. In general pull interfaces handle backpressure better.
Hope that helps.
Ben
Cheers,
David
On 19/06/15 20:09, Benjamin Kelly wrote:
Also, I have setup a session on streams in the DOM room at Whistler:
http://juneworkweekwhistler2015.sched.org/event/28ff926a768953ba39a44cd36598d7f7
Please stop by if you have questions or just want to talk about it.
Thanks!
Ben
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: intent to implement Streams
On Fri, Jun 19, 2015 at 3:03 PM, Benjamin Kelly bke...@mozilla.com wrote:
You could also use ReadableStream, but it doesn't look as similar to
observables:
var reader = data.getStream().getReader();
reader.read().then(function handleRead(value) {
handleNext(value);
return reader.read().then(handleRead);
}).catch(handleError);
reader.closed.then(handleComplete);
Sorry, this one is probably better written with the
ReadStream-to-WritableStream adapter function pipeTo():
data..getStream().pipeTo(new WritableStream({
write: handleNext,
close: handleComplete,
abort: handleError
}));
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
