Re: Good ways to view Firefox compile errors in a terminal?
Sublime Text has quite good support too.
F4 navigates you to the next error, opens the file (if it's not opened)
and moves the cursor to the error location.
Jan
On 13/01/15 17:52, Nick Fitzgerald wrote:
For those of us using Emacs:
I use M-x shell as my terminal, and when combined with
compilation-shell-minor-mode, I get the following goodies:
* Compilation errors get "syntax" highlighted
* Putting the cursor on an error line and pressing RET opens the file in a
new (or its existing) buffer and moves the cursor to the error location
* C-M-n navigates the cursor to the next compilation error
* C-M-p navigates the cursor to the previous compilation error
Very fast, very integrated!
On Mon, Jan 12, 2015 at 2:09 PM, Nicholas Nethercote
wrote:
Hi,
If you do |mach build| and get compile errors, often those errors
scroll quickly off screen and they are mixed in with other lines of
output and it's hard to find them.
I deal with this by using a bash alias that calls |mach build| and
pipes the output to file. I can then use Vim's quicklists feature to
jump directly to errors in the file. But sometimes I just want to
eyeball the errors directly in the terminal, so in my alias I also
have a post-build step that greps the output file for the first five
error messages.
This setup works well for me but it's also kinda gross [1] and this
seems like a problem that everybody else working on C++ code has to
deal with as well. So I'm wondering if there are other, better ways of
doing it, and if so, could they be made automatic? There is |mach
warnings-list| which is sort of like this, but not quite.
Thanks.
Nick
[1] How gross? Here are the two most important lines:
# Send mach's raw output to stdout and $config/log, and the
# timestamp-stripped output to errors.err. The "$| = 1" disables Perl's
# buffering, so the output is available immediately.
MOZCONFIG=$HOME/moz/config/$config nice mach build $restdir 2>&1 | \
tee >(perl -p -e '$| = 1; s/^ *\d+:\d\d\.\d\d //' > errors.err) \
$config/log
# Show up to five errors, with 10 lines of trailing context each. But
# first, truncate line length to 300 chars (because I sometimes get
# extremely long lines describing the command line used, which are
# annoying).
perl -p -e 's/^(.{300}).*$/\1/' $config/log | \
grep --max-count=5 --before-context=3 --after-context=10 "\https://lists.mozilla.org/listinfo/dev-platform
___
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: Enhancing Gecko as a WebGL game platform
On Tue, Jan 13, 2015 at 10:56 AM, Mike de Boer wrote: > > 2. Optionally bypass the browser compositor when a WebGL context is in > fullscreen mode. In this mode, WebGL draw calls would write to the OS back > buffer directly, increasing performance. Of course, this would never be > possible if the WebGL context has to be rendered amidst other HTML elements > on a web page, so that’s why the proposition here is for fullscreen mode > only. > There was a thread on this on the public webgl mailing list recently: https://www.khronos.org/webgl/public-mailing-list/archives/1412/msg00062.html Interestingly enough, I believe Safari and IE already avoid the problem this would solve because they use the system compositor to composite there layers instead of a built-in one. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enhancing Gecko as a WebGL game platform
On Wed, Jan 14, 2015 at 4:56 AM, Mike de Boer wrote: > 2. Optionally bypass the browser compositor when a WebGL context is in > fullscreen mode. In this mode, WebGL draw calls would write to the OS back > buffer directly, increasing performance. Of course, this would never be > possible if the WebGL context has to be rendered amidst other HTML elements > on a web page, so that’s why the proposition here is for fullscreen mode > only. > Can you get more data about what their goal is here? Reducing latency? Reducing bandwidth? Something else? Letting the app write directly to the backbuffer seems like it would create problems if, say, the user switches tabs while the app is drawing, but maybe there's a way around that. Maybe there's another way to achieve whatever their goal is. 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: Enhancing Gecko as a WebGL game platform
On Tue, Jan 13, 2015 at 8:24 PM, Luke Wagner wrote: > > Do you know what they actually mean when they use the term "hardware > > pointer"? > > > > I believe what he's referring to is the type of hardware-accelerated cursor > support discussed here: > > > http://technet.microsoft.com/en-us/magazine/2009.02.windowsconfidential.aspx?pr=blog > and here > http://blogs.unity3d.com/2012/10/22/cursor-api/ > In my experience, if your game wasn't getting great or regular framerate, > the hardware cursor could make the mouse feel a lot snappier. > Adobe introduced support for this in Flash as well a few years ago: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ui/Mouse.html#registerCursor%28%29 I remember that people had been wanting it for a long time. ( And yes, that does mean that ideally we'd be able to support it in Shumway :) ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enhancing Gecko as a WebGL game platform
> Do you know what they actually mean when they use the term "hardware > pointer"? > I believe what he's referring to is the type of hardware-accelerated cursor support discussed here: http://technet.microsoft.com/en-us/magazine/2009.02.windowsconfidential.aspx?pr=blog and here http://blogs.unity3d.com/2012/10/22/cursor-api/ In my experience, if your game wasn't getting great or regular framerate, the hardware cursor could make the mouse feel a lot snappier. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cross origin communication and the navigator.connect API
On 2015-01-07 3:34 AM, kenjibah...@chromium.org wrote:
On Thursday, December 11, 2014 10:45:26 AM UTC+9, Ehsan Akhgari wrote:
On 2014-12-10 3:32 PM, Jonas Sicking wrote:
I think instead the proposal is to enable a SW from website A to say
"please consult me for any network requests to https://a.com/apis/*";.
Then if website B makes a network request to
https://a.com/apis/whatnot, it would first go to B's SW as per current
SW specifications. But if that SW decides to forward the request to
the network, then rather than directly hitting the network, first go
to A's SW.
Same thing if B's SW for any other reason makes a network request to
https://a.com/apis/whatnot. Rather than directly hitting the network
as is currently defined, we'd first go to A's SW.
Yes, that is exactly what I had in mind.
I would love to see something like this.
I'm happy to hear someone inside Google is interested in this as well!
Third party services (e.g. Analytics, Fonts, Social) should be able to declare
that they have a Service Worker that will happily take care of the requests
that are relevant for them if the current site's SW (if any) let them through.
Failing that, we might see a proliferation of sites that go through the trouble
of offlining these third party services themselves in their quest of nailing
their own offline-first user experience. For Fonts, we'll loose on cache hit
opportunities since that site's SW will most likely put them in its same-origin
restricted Cache.
Also, letting these third party services take matters into their own hands
opens up interesting opportunities.
For instance, a Fonts service provider might want to use the background sync
API to regularly rationalize its Fonts cache:
- pruning infrequently used fonts
- prefetching popular fonts for a given market
- fetching the whole font after seeing several requests for bits of it via
dynamic subtyping or unicode-range (e.g. CJK fonts can be quite huge)
- mapping subset requests to the whole font there after
Agreed.
I think these use cases lead to the following requirements:
1. The third party service is able to tell the UA to install and optionally
activate right away its service worker from the client site
Naive strawman: the client site added a script tag pointing to the third
party's bootstrap JavaScript; the boostrap Javascript code calls
navigator.connect(url of third party's SW, {takeControl: true/(default:false)})
UA installs the SW if needed.
takeControl: true would activate the SW right away
I thought that navigator.connect() as envisioned by
is about letting
websites communicate to SWs, not let them register one. It seems like
#1 above is about registration. Is there any reason to not extend the
existing SW registration mechanism?
2. The third party service is able to tell the UA that its SW is happy to
take care of in-scope requests that the client site's SW (if any) has decided
to let go through.
Naive strawman: an extra parameter (consulted... ahem, couldn't think of
anything better...) => navigator.connect(url of third party's SW, {consulted:
true})
I'd argue that when the SW for site A lets a request for site B to go to
the network, we should consult B's SW (or a special cross-origin
handling SW from B) if one is present before going to the network by
default.
3. The third party service is able to tell the UA that its SW is happy to
take care of in-scope requests that any client site didn't deal with (via a SW).
Isn't this the same thing as #1?
I *think* this is needed for the Fonts service use case where relevant
requests [1] might trigger before the third party bootstrap script has a chance
to run.
Well, we only have this problem if the embedding website triggers the
registration as well. I think we can avoid the issue if we let that
website handle its own registration in the normal way.
Naively, a previous call to navigator.connect(url, {consulted: true}) would
make that happen by default but I'm probably missing something important that
makes this a bad idea.
I'm still struggling to understand what exactly navigator.connect() as
proposed does. :-)
Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Compiling m-c within Emacs (was: Re: Good ways to view Firefox compile errors in a terminal?)
On Tue, Jan 13, 2015 at 10:01 AM, Nathan Froyd wrote: > On Tue, Jan 13, 2015 at 11:52 AM, Nick Fitzgerald > wrote: > >> For those of us using Emacs: >> >> I use M-x shell as my terminal, and when combined with >> compilation-shell-minor-mode, I get the following goodies: > > > FYI, you can use M-x compile (or at least a wrapper around it) with a bit > of cleverness: > > (defun froydnj-build-mozilla-with-mozconfig (mozconfig target) > (let* ((objdir (shell-command-to-string > (format "grep MOZ_OBJDIR %s | cut -f 2 -d =" mozconfig))) > ;; Use the first cd command so compile's intelligent setting of > ;; default-directory works to our advantage. Use the second cd > ;; command so mach is invoked from the correct directory. > (compile-command (format "cd %s; cd %s; env MOZCONFIG=%s mach > --log-no-times build %s" > (remove-if #'(lambda (x) (char-equal x > ?\n)) > objdir :from-end t :count 1) > froydnj-mozilla-srcdir > mozconfig > target))) > (compile compile-command))) > > This gets invoked from some machinery to choose which mozconfig (six > different mozconfigs so far, full builds or "binaries" builds), but the > idea should be clear. By setting compilation-buffer-name-function > appropriately, separate mozconfigs produce their compilation output in > separate buffers, and one can avoid cluttering up shells with compilation > output. > > -Nathan > I have my own compile function that I bind to C-c C-c, that uses the shell buffer instead of the compilation buffer (I prefer to have it all integrated in one place): (defun clear-shell-buffer () (interactive) (let ((comint-buffer-maximum-size 0)) (comint-truncate-buffer))) (defun my-compile (cmd) (interactive (list (compilation-read-command compile-command))) (if (get-buffer "*shell*") (switch-to-buffer-other-window "*shell*") (shell)) (clear-shell-buffer) (end-of-buffer) (comint-kill-input) (insert cmd) (end-of-line) (comint-send-input) (unless (equal cmd (eval compile-command)) (setq compile-command cmd))) The first time you compile, you have to enter the compilation command: C-c C-c ./mach build subdir RET But after that, the cmd is remembered and you can simply do: C-c C-c RET ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Good ways to view Firefox compile errors in a terminal?
On Tue, Jan 13, 2015 at 11:52 AM, Nick Fitzgerald wrote: > For those of us using Emacs: > > I use M-x shell as my terminal, and when combined with > compilation-shell-minor-mode, I get the following goodies: FYI, you can use M-x compile (or at least a wrapper around it) with a bit of cleverness: (defun froydnj-build-mozilla-with-mozconfig (mozconfig target) (let* ((objdir (shell-command-to-string (format "grep MOZ_OBJDIR %s | cut -f 2 -d =" mozconfig))) ;; Use the first cd command so compile's intelligent setting of ;; default-directory works to our advantage. Use the second cd ;; command so mach is invoked from the correct directory. (compile-command (format "cd %s; cd %s; env MOZCONFIG=%s mach --log-no-times build %s" (remove-if #'(lambda (x) (char-equal x ?\n)) objdir :from-end t :count 1) froydnj-mozilla-srcdir mozconfig target))) (compile compile-command))) This gets invoked from some machinery to choose which mozconfig (six different mozconfigs so far, full builds or "binaries" builds), but the idea should be clear. By setting compilation-buffer-name-function appropriately, separate mozconfigs produce their compilation output in separate buffers, and one can avoid cluttering up shells with compilation output. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enhancing Gecko as a WebGL game platform
> On 13 Jan 2015, at 18:23, Ehsan Akhgari wrote:
>
> On 2015-01-13 10:56 AM, Mike de Boer wrote:
>> Hi all,
>>
>> I’ve been having interesting discussions with a WebGL game developer, whose
>> employer is betting big on the Web Platform as the foundation for their
>> games currently in development.
>> I asked him what the most interesting features and improvements would be to
>> allow them to keep betting on the Web as their development platform of
>> choice; two requests surfaced as must-haves:
>>
>> 1. Optional access to the hardware pointer/ cursor as a possible extension
>> to the pointerLock(Element) API to have better performance when capturing
>> the cursor and the optional ability to restrict mouse movement within a
>> rect. One example might be:
>>
>> requestPointerLock({clipRect: [0, 0, window.innerWidth, window.innerHeight],
>> useHardwareCursor: true})
>>
>> … where clipRect could also be a DOMRect (if it can be instantiated from
>> content), for example. The point here is to allow for more control over the
>> cursor and accessibility to a more direct pointer layer.
>
> Do you know what they actually mean when they use the term "hardware pointer”?
Not exactly, but I think their point is mostly to get access to pointer
coordinates at the lowest possible level, circumventing as many (DOM)
processing layers as possible.
>
>> 2. Optionally bypass the browser compositor when a WebGL context is in
>> fullscreen mode. In this mode, WebGL draw calls would write to the OS back
>> buffer directly, increasing performance. Of course, this would never be
>> possible if the WebGL context has to be rendered amidst other HTML elements
>> on a web page, so that’s why the proposition here is for fullscreen mode
>> only.
>
> This seems like an implementation optimization that the browser could be
> doing if it detects that there is only one canvas made full screen with no
> other elements over/under-laying it. Right?
>
Exactly!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Enhancing Gecko as a WebGL game platform
On 2015-01-13 10:56 AM, Mike de Boer wrote:
Hi all,
I’ve been having interesting discussions with a WebGL game developer, whose
employer is betting big on the Web Platform as the foundation for their games
currently in development.
I asked him what the most interesting features and improvements would be to
allow them to keep betting on the Web as their development platform of choice;
two requests surfaced as must-haves:
1. Optional access to the hardware pointer/ cursor as a possible extension to
the pointerLock(Element) API to have better performance when capturing the
cursor and the optional ability to restrict mouse movement within a rect. One
example might be:
requestPointerLock({clipRect: [0, 0, window.innerWidth, window.innerHeight],
useHardwareCursor: true})
… where clipRect could also be a DOMRect (if it can be instantiated from
content), for example. The point here is to allow for more control over the
cursor and accessibility to a more direct pointer layer.
Do you know what they actually mean when they use the term "hardware
pointer"?
2. Optionally bypass the browser compositor when a WebGL context is in
fullscreen mode. In this mode, WebGL draw calls would write to the OS back
buffer directly, increasing performance. Of course, this would never be
possible if the WebGL context has to be rendered amidst other HTML elements on
a web page, so that’s why the proposition here is for fullscreen mode only.
This seems like an implementation optimization that the browser could be
doing if it detects that there is only one canvas made full screen with
no other elements over/under-laying it. Right?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Good ways to view Firefox compile errors in a terminal?
For those of us using Emacs:
I use M-x shell as my terminal, and when combined with
compilation-shell-minor-mode, I get the following goodies:
* Compilation errors get "syntax" highlighted
* Putting the cursor on an error line and pressing RET opens the file in a
new (or its existing) buffer and moves the cursor to the error location
* C-M-n navigates the cursor to the next compilation error
* C-M-p navigates the cursor to the previous compilation error
Very fast, very integrated!
On Mon, Jan 12, 2015 at 2:09 PM, Nicholas Nethercote wrote:
> Hi,
>
> If you do |mach build| and get compile errors, often those errors
> scroll quickly off screen and they are mixed in with other lines of
> output and it's hard to find them.
>
> I deal with this by using a bash alias that calls |mach build| and
> pipes the output to file. I can then use Vim's quicklists feature to
> jump directly to errors in the file. But sometimes I just want to
> eyeball the errors directly in the terminal, so in my alias I also
> have a post-build step that greps the output file for the first five
> error messages.
>
> This setup works well for me but it's also kinda gross [1] and this
> seems like a problem that everybody else working on C++ code has to
> deal with as well. So I'm wondering if there are other, better ways of
> doing it, and if so, could they be made automatic? There is |mach
> warnings-list| which is sort of like this, but not quite.
>
> Thanks.
>
> Nick
>
> [1] How gross? Here are the two most important lines:
>
> # Send mach's raw output to stdout and $config/log, and the
> # timestamp-stripped output to errors.err. The "$| = 1" disables Perl's
> # buffering, so the output is available immediately.
> MOZCONFIG=$HOME/moz/config/$config nice mach build $restdir 2>&1 | \
> tee >(perl -p -e '$| = 1; s/^ *\d+:\d\d\.\d\d //' > errors.err) \
> $config/log
>
> # Show up to five errors, with 10 lines of trailing context each. But
> # first, truncate line length to 300 chars (because I sometimes get
> # extremely long lines describing the command line used, which are
> # annoying).
> perl -p -e 's/^(.{300}).*$/\1/' $config/log | \
> grep --max-count=5 --before-context=3 --after-context=10 "\ ___
> 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: Unified compilation is going to ride the train
I have started to work on removing support for non-unified builds over in bug 1121000.x On Thu, Nov 27, 2014 at 8:12 PM, Mike Hommey wrote: > Hi, > > A year ago, when unified compilation was introduced to speed up builds, > a couple issues were raised and we conservatively restricted them out > of aurora/beta/release/esr. > > A year later, it's time to revisit this decision, and since afaik we > haven't had problems specific to unified compilation on nightlies, > including for crash reports, we can assume the issues are either gone > or didn't exist in the first place (one problem that comes to mind is > bug 943695, and it probably isn't a problem in practice, although weird) > > I know a lot of people have burned non-unified builds now and then. > That's an annoyance and a distraction for getting things done. If > unified compilation rides up to beta and we don't see significant > problems, I think we can disable all periodic non-unified builds > and make the few builds that are always non-unified unified again (a few > debug builds are this way). > > The downside from doing so, though, is that non-unified build *will* > be broken, and code "purity" (right includes in the right sources, > mostly) won't be ensured. Do you think this is important enough to keep > non-unified builds around? > > Mike > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enhancing Gecko as a WebGL game platform
On Tue, Jan 13, 2015 at 4:56 PM, Mike de Boer wrote:
> 1. Optional access to the hardware pointer/ cursor as a possible extension to
> the pointerLock(Element) API to have better performance when capturing the
> cursor and the optional ability to restrict mouse movement within a rect. One
> example might be:
>
> requestPointerLock({clipRect: [0, 0, window.innerWidth, window.innerHeight],
> useHardwareCursor: true})
>
> … where clipRect could also be a DOMRect (if it can be instantiated from
> content), for example. The point here is to allow for more control over the
> cursor and accessibility to a more direct pointer layer.
They could do this by just having a dummy element, no? Is this being
suggested because of the other suggestion in which case you wouldn't
want to have such a dummy element overlaying a part of the screen?
> Is WebGL game development something we ought to focus on and cater to?
Making the web attractive for gaming seems extremely relevant to what
we are trying to do overall, so yes.
--
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Enhancing Gecko as a WebGL game platform
Hi all,
I’ve been having interesting discussions with a WebGL game developer, whose
employer is betting big on the Web Platform as the foundation for their games
currently in development.
I asked him what the most interesting features and improvements would be to
allow them to keep betting on the Web as their development platform of choice;
two requests surfaced as must-haves:
1. Optional access to the hardware pointer/ cursor as a possible extension to
the pointerLock(Element) API to have better performance when capturing the
cursor and the optional ability to restrict mouse movement within a rect. One
example might be:
requestPointerLock({clipRect: [0, 0, window.innerWidth, window.innerHeight],
useHardwareCursor: true})
… where clipRect could also be a DOMRect (if it can be instantiated from
content), for example. The point here is to allow for more control over the
cursor and accessibility to a more direct pointer layer.
2. Optionally bypass the browser compositor when a WebGL context is in
fullscreen mode. In this mode, WebGL draw calls would write to the OS back
buffer directly, increasing performance. Of course, this would never be
possible if the WebGL context has to be rendered amidst other HTML elements on
a web page, so that’s why the proposition here is for fullscreen mode only.
What do you think? Is WebGL game development something we ought to focus on and
cater to?
One last thing I was wondering is whether we already have settings for v-sync
and GPU switching accessible from privileged content?
All the best,
Mike.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
