After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732349 - Fixes for perf framework
Fixes for perf framework
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-06-27 15:06 UTC by Owen Taylor
Modified: 2014-06-29 22:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Scripting: exit if the perf script throws an error during collection (1.11 KB, patch)
2014-06-27 15:06 UTC, Owen Taylor
committed Details | Review
perf: fix bug in code to print out metrics (1.31 KB, patch)
2014-06-27 15:06 UTC, Owen Taylor
committed Details | Review
Scripting.createTestWindow(): take params (3.22 KB, patch)
2014-06-27 15:06 UTC, Owen Taylor
committed Details | Review
Scripting: catch errors from shell-perf-helper (3.62 KB, patch)
2014-06-27 15:07 UTC, Owen Taylor
committed Details | Review

Description Owen Taylor 2014-06-27 15:06:48 UTC
Here are some miscellaneous fixes and cleanups for the perf framework;
I'll file another bug in a second that depends on these fixes and adds
a new performance script used for hardware performance testing.
Comment 1 Owen Taylor 2014-06-27 15:06:51 UTC
Created attachment 279409 [details] [review]
Scripting: exit if the perf script throws an error during collection

If an exception occurs while collecting parameters, exit rather than
just leaving the shell running in the main loop.
Comment 2 Owen Taylor 2014-06-27 15:06:56 UTC
Created attachment 279410 [details] [review]
perf: fix bug in code to print out metrics

We don't normally hit the code in scripting.js to print metrics
because shell-perf-tool bypasses it, but there was a left-over
in the code that no longer works. Also add in the units to the
output.
Comment 3 Owen Taylor 2014-06-27 15:06:58 UTC
Created attachment 279411 [details] [review]
Scripting.createTestWindow(): take params

Take a parameter object rather than a long parameter list containing
multiple booleans.
Comment 4 Owen Taylor 2014-06-27 15:07:06 UTC
Created attachment 279412 [details] [review]
Scripting: catch errors from shell-perf-helper

When calling remote D-Bus methods, handle exceptions, log them
and exit, rather than just proceeding as if nothing happened.
Comment 5 Jasper St. Pierre (not reading bugmail) 2014-06-27 20:34:47 UTC
Review of attachment 279409 [details] [review]:

OK.
Comment 6 Jasper St. Pierre (not reading bugmail) 2014-06-27 20:35:50 UTC
Review of attachment 279410 [details] [review]:

OK.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-06-27 20:36:14 UTC
Review of attachment 279411 [details] [review]:

OK.
Comment 8 Jasper St. Pierre (not reading bugmail) 2014-06-27 20:41:51 UTC
Review of attachment 279412 [details] [review]:

OK.

::: js/ui/scripting.js
@@ +103,3 @@
+    let errcb;
+
+    let args = Array.slice(arguments, 2);

Hm, I didn't expect that to work. Turns out it's an undocumented part of Mozilla JS. I'd use the more traditional [].slice.call(arguments, 2);
Comment 9 Owen Taylor 2014-06-27 22:01:52 UTC
(In reply to comment #8)
> Review of attachment 279412 [details] [review]:
> 
> OK.
> 
> ::: js/ui/scripting.js
> @@ +103,3 @@
> +    let errcb;
> +
> +    let args = Array.slice(arguments, 2);
> 
> Hm, I didn't expect that to work. Turns out it's an undocumented part of
> Mozilla JS. I'd use the more traditional [].slice.call(arguments, 2);

It's documented in MDN (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array - see "Array Generic Methods") But yeah, somehow I had it in my head that it was scheduled for Ecmascript 6 and it's not.

Even if JS engines optimize out the allocation in [].slice.call(), it still looks pretty ugly to me, Array.prototype.slice.call(arguments, 2) seems cleaner.

Or how do you feel about using something that *is* slated for Ecmascript 6 

 function _callRemote(obj, method, ...args)  {
 }

?
Comment 10 Jasper St. Pierre (not reading bugmail) 2014-06-27 22:11:11 UTC
(In reply to comment #9)
> Or how do you feel about using something that *is* slated for Ecmascript 6 
> 
>  function _callRemote(obj, method, ...args)  {
>  }
> 
> ?

As long as it works in gjs, sure.
Comment 11 Owen Taylor 2014-06-29 22:31:16 UTC
Pushing (with change to use ...args)

Attachment 279409 [details] pushed as 910c95f - Scripting: exit if the perf script throws an error during collection
Attachment 279410 [details] pushed as e375e1a - perf: fix bug in code to print out metrics
Attachment 279411 [details] pushed as f285f2c - Scripting.createTestWindow(): take params
Attachment 279412 [details] pushed as 2fbd8f0 - Scripting: catch errors from shell-perf-helper