Argument validation as a JSM?
I've been thinking a bit about writing a JSM for validating arguments coming into a function. The first part would be the set of assertion functions: * a non-empty string * a whole number * a positive number * a non-negative number * a function * instanceof * typeof * member of a set * Custom validation function returning true or false * etc. The second part would be how to respond to an assertion failure: * Throw an Error * Throw Components.Exception * Report to JS console service * Report to a provided Log.jsm logger * Trigger a debugger keyword * Custom failure function * Ordered combinations of the above Above all else, the module should have a simple API. Something like this could be useful throughout the Mozilla codebase, and for addons or custom XULRunner applications. Suggestions? If there's an existing module out there, I'd like to hear of it before reinventing the wheel. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: On 2014-05-13, 9:01 PM, Rik Cabanier wrote: ... The problem is that the API doesn't really make it obvious that you're not supposed to take the value that the getter returns and just spawn N workers. IOW, the API encourages the wrong behavior by design. That is simply untrue. I'm assuming that the goal of this API is to allow authors to spawn as many workers as possible so that they can exhaust all of the cores in the interest of finishing their computation faster. That is one way of using it but not the only one. For instance, let's say that I'm writing on a cooperative game. I might want to put all my network logic in a worker and want to make sure that worker is scheduled. This worker consumes little (if any) cpu, but I want it to be responsive. NumCores = 1 - do everything in the main thread and try to make sure the network code executes NumCores = 2 - spin up a worker for the network code. Everything else in the main thread NumCores = 3 - spin up a worker for the network code + another one for physics and image decompression. Everything else in the main thread I have provided reasons why any thread which is running at a higher priority on the system busy doing work is going to make this number an over approximation, I have given you two examples of higher priority threads that we're currently shipping in Firefox (Chrome Workers and the MediaStreamGraph thread) You're arguing against basic multithreading functionality. I'm unsure how ANY thread framework in a browser could fix this since there might be other higher priority tasks in the system. For your example of Chrome Workers and MediaStreamGraph, I assume those don't run at a constant 100% so a webapp that grabs all cores will still get more work done. and have provided you with experimental evidence of running Eli's test cases trying to exhaust as many cores as it can fails to predict the number of cores in these situations. Eli's code is an approximation. It doesn't prove anything. I don't understand your point here. If you don't find any of this convincing, I'd respectfully ask us to agree to disagree on this point. OK. For the sake of argument, let's say you are right. How are things worse than before? I don't think we should necessarily try to find a solution that is just not worse than the status quo, I'm more interested in us implementing a good solution here (and yes, I'm aware that there is no concrete proposal out there that is better at this point.) So, worst case, there's no harm. Best case, we have a more responsive application. ... That's fine but we're coming right back to the start: there is no way for informed authors to make a decision today. Yes, absolutely. The let's build something complex that solves everything proposal won't be done in a long time. Meanwhile apps can make responsive UI's and fluid games. That's I think one fundamental issue we're disagreeing on. I think that apps can build responsive UIs and fluid games without this today on the Web. Sure. You can build apps that don't tax the system or that are specifically tailored to work well on a popular system. There were 24,000 hits for java which is on the web and a VM but now you say that it's not a vote of popularity? We may have a different terminology here, but to me, positive feedback from web developers should indicate a large amount of demand from the web developer community for us to solve this problem at this point, and also a strong positive signal from them on this specific solution with the flaws that I have described above in mind. That simply doesn't map to searching for API names on non-Web technologies on github. :-) This was not a simple search. Please look over the examples especially the node.js ones and see how it's being used. This is what we're trying to achieve with this attribute. Also, FTR, I strongly disagree that we should implement all popular Java APIs just because there is a way to run Java code on the web. ;-) ... Can you restate the actual problem? I reread your message but didn't find anything that indicates this is a bad idea. See above where I re-described why this is not a good technical solution to achieve the goal of the API. Also, as I've mentioned several times, this API basically ignores the fact that there are AMP systems shipping *today* and dies not take the fact that future Web engines may try to use as many cores as they can at a higher priority (Servo being one example.) OK. They're free to do so. This is not a problem (see previous messages) It seems like you're arguing against basic multithreading again. Others do this is just not going to convince me here. What would convince you? The fact that every other framework provides this and people use it, is not a strong indication? It's not possible for me
Re: Argument validation as a JSM?
I remember opening a bug for this ~2.5 years ago. The answer was that most of these assertions are so trivial to write that putting them in a module would actually make reading the code harder than simpler. I don't think the situation has changed since then. Cheers, David On 15/05/14 08:04, ajvinc...@gmail.com wrote: I've been thinking a bit about writing a JSM for validating arguments coming into a function. The first part would be the set of assertion functions: * a non-empty string * a whole number * a positive number * a non-negative number * a function * instanceof * typeof * member of a set * Custom validation function returning true or false * etc. The second part would be how to respond to an assertion failure: * Throw an Error * Throw Components.Exception * Report to JS console service * Report to a provided Log.jsm logger * Trigger a debugger keyword * Custom failure function * Ordered combinations of the above Above all else, the module should have a simple API. Something like this could be useful throughout the Mozilla codebase, and for addons or custom XULRunner applications. Suggestions? If there's an existing module out there, I'd like to hear of it before reinventing the wheel. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Argument validation as a JSM?
I agree with what David said; it usually makes the code harder to read, but that also greatly depends on the exposed API of the library. Assertions are a widely-known, commonly accepted way to do in-method validation. I quite recently wrote Assert.jsm (http://dxr.mozilla.org/mozilla-central/source/testing/modules/Assert.jsm), which you can include like this: ```js Components.utils.import(resource://testing-common/Assert.jsm”); ``` You can also control how assertion errors are reported, so you can make it do the things you listed. By default, it’ll throw an AssertionError object, which inherits from Error.prototype. I hope you’ll find it useful! Have fun, Mike. On 15 May 2014, at 11:17, David Rajchenbach-Teller dtel...@mozilla.com wrote: I remember opening a bug for this ~2.5 years ago. The answer was that most of these assertions are so trivial to write that putting them in a module would actually make reading the code harder than simpler. I don't think the situation has changed since then. Cheers, David On 15/05/14 08:04, ajvinc...@gmail.com wrote: I've been thinking a bit about writing a JSM for validating arguments coming into a function. The first part would be the set of assertion functions: * a non-empty string * a whole number * a positive number * a non-negative number * a function * instanceof * typeof * member of a set * Custom validation function returning true or false * etc. The second part would be how to respond to an assertion failure: * Throw an Error * Throw Components.Exception * Report to JS console service * Report to a provided Log.jsm logger * Trigger a debugger keyword * Custom failure function * Ordered combinations of the above Above all else, the module should have a simple API. Something like this could be useful throughout the Mozilla codebase, and for addons or custom XULRunner applications. Suggestions? If there's an existing module out there, I'd like to hear of it before reinventing the wheel. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ 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: Proposed changes to autocomplete administrative levels
On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson bnichol...@mozilla.com wrote: If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can't simply provide a single blob for an entire address as sites generally require more tokenized information. You do not want to tie this to a particular localization. E.g. I use the en-US version of Firefox, but I make payments with European credit cards. Localization should not affect functionality. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Application MAR-file auto Update not working from 29.0 to 29.0.1
Hi, This is my first post in this forum so please let me know if anything is wrong. I have been working on a desktop application named AZARDI which is based on xulrunner. It is an offline ePub Reader for all three major platforms (Windows, Mac, Linux). You can check it out at http://azardi.infogridpacific.com/. I have been deploying the application successfully with xulrunner 29.0 and earlier along with the mar auto-update. Now I want to deploy it with xulrunner 29.0.1 and thats when I am facing the problem. The mar auto-update thing seems not to be working across all the platforms. Once the mar-update is downloaded and I restart the application, the updates didn't get applied and when I went on to check the last-update.log, this is what I found: SOURCE DIRECTORY C:\Users\$USER$\AppData\Local\\.\\\updates\0 DESTINATION DIRECTORY C:\Program Files\infogridpacific\AZARDI DoUpdate: error extracting manifest file failed: 6 calling QuitProgressUI Does anyone know if there is any change in auto-update strategy after xulrunner 29.0 ? And is there any other solution to the above problem? Any help will be useful. Thanks in advance. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Application MAR-file auto Update not working from 29.0 to 29.0.1
On 14-05-15 08:46 AM, Manish wrote: Hi, This is my first post in this forum so please let me know if anything is wrong. I have been working on a desktop application named AZARDI which is based on xulrunner. It is an offline ePub Reader for all three major platforms (Windows, Mac, Linux). You can check it out at http://azardi.infogridpacific.com/. I have been deploying the application successfully with xulrunner 29.0 and earlier along with the mar auto-update. Now I want to deploy it with xulrunner 29.0.1 and thats when I am facing the problem. The mar auto-update thing seems not to be working across all the platforms. Once the mar-update is downloaded and I restart the application, the updates didn't get applied and when I went on to check the last-update.log, this is what I found: SOURCE DIRECTORY C:\Users\$USER$\AppData\Local\\.\\\updates\0 DESTINATION DIRECTORY C:\Program Files\infogridpacific\AZARDI DoUpdate: error extracting manifest file failed: 6 calling QuitProgressUI Does anyone know if there is any change in auto-update strategy after xulrunner 29.0 ? And is there any other solution to the above problem? Any help will be useful. Thanks in advance. I'm pretty sure that error number (6) corresponds to the ones in this file: https://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/common/errors.h Is your MAR corrupted? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed changes to autocomplete administrative levels
On May 15, 2014, at 9:29, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson bnichol...@mozilla.com wrote: If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can't simply provide a single blob for an entire address as sites generally require more tokenized information. You do not want to tie this to a particular localization. E.g. I use the en-US version of Firefox, but I make payments with European credit cards. Localization should not affect functionality. I don’t think that’s even possible. As Brian said: In short, every localizer would need to be able to translate every other countries' administrative levels. The en-US locale (and every other locale) would need to have English translations for European countries’ administrative level names. -- reuben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed changes to autocomplete administrative levels
On Thu, May 15, 2014 at 5:02 PM, Reuben Morais reuben.mor...@gmail.com wrote: The en-US locale (and every other locale) would need to have English translations for European countries’ administrative level names. Yes. Not being able to use this feature with a credit card from Switzerland and an English Firefox would be bad. I'm not saying we need to solve this for v1, but it should definitely be part of the platform long term. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Argument validation as a JSM?
Re: readability, that's something to think about, but when I write code like
this:
if ((typeof num != number) ||
(Math.floor(num) != num) ||
isNaN(num) ||
(num 0) ||
Math.abs(num) == Infinity) {
throw new Error(This need to be a non-negative whole number);
}
Well, it adds up. :) Even now I can replace the fifth condition with
!Number.isFinite(num).
Actually, I've always wondered if validating and throwing early because an
argument doesn't meet a constraint might be a hint to the underlying JS engine
that it could convert the argument to a stricter type after the validation for
performance. (No floating-point number can get past that throw; it'd have to
be an unsigned integer.) But I'm betting the perf gain might not be all that
great. If it were, that might justify the readability issue.
Would splitting into two functions help, if the first were arg validation only?
(I hope it wouldn't help... but if it did, I'd do it.)
Re: Assert.jsm: Too bad it's not available in release builds. Also, isn't it
generally accepted that asserts are for test and debug code only? Argument
validation isn't a debugging-only problem.
A couple other notes:
* XPConnect obviously does some type coercion, but that's a pretty big hammer,
as Brendan used to put it.
* None of these solutions does anything for workers, particularly since workers
can't load JSM's.
On Thursday, May 15, 2014 2:38:21 AM UTC-7, Mike de Boer wrote:
I quite recently wrote Assert.jsm
(http://dxr.mozilla.org/mozilla-central/source/testing/modules/Assert.jsm),
which you can include like this:
Components.utils.import(resource://testing-common/Assert.jsm);
On 15 May 2014, at 11:17, David Rajchenbach-Teller dtel...@mozilla.com
wrote:
I remember opening a bug for this ~2.5 years ago. The answer was that
most of these assertions are so trivial to write that putting them in a
module would actually make reading the code harder than simpler. I don't
think the situation has changed since then.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Argument validation as a JSM?
On 05/15/2014 05:58 PM, ajvinc...@gmail.com wrote:
Re: readability, that's something to think about, but when I write code like
this:
if ((typeof num != number) ||
(Math.floor(num) != num) ||
isNaN(num) ||
(num 0) ||
Math.abs(num) == Infinity) {
throw new Error(This need to be a non-negative whole number);
}
Well, it adds up. :) Even now I can replace the fifth condition with
!Number.isFinite(num).
One could use if ((num | 0) !== num) { ... }. That should be
equivalent for 32-bit unsigned integers.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: navigator.hardwareConcurrency
On May 15, 2014, at 1:26 AM, Rik Cabanier caban...@gmail.com wrote: On Wed, May 14, 2014 at 11:39 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: ... Make it possible for authors to make a semi-informed decision on how to divide the work among workers. That can already be done using the timing attacks at the waste of some CPU time. It's imprecise and wasteful. A simple attribute check is all this should take. If we want to support games on mobile platforms like Firefox OS, then this seems like a pretty important point. Do we really want apps on buri (or tarako) wasting CPU, memory, and power to determine that they should not spin up web workers? Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Application MAR-file auto Update not working from 29.0 to 29.0.1
That error is due to not having an update manifest in the mar and implies that the update mar wasn't generated with a manifest. http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updat er/updater.cpp#3700 Robert -Original Message- From: dev-platform [mailto:dev-platform-bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Manish Sent: Thursday, May 15, 2014 5:47 AM To: dev-platform@lists.mozilla.org Subject: Application MAR-file auto Update not working from 29.0 to 29.0.1 Hi, This is my first post in this forum so please let me know if anything is wrong. I have been working on a desktop application named AZARDI which is based on xulrunner. It is an offline ePub Reader for all three major platforms (Windows, Mac, Linux). You can check it out at http://azardi.infogridpacific.com/. I have been deploying the application successfully with xulrunner 29.0 and earlier along with the mar auto-update. Now I want to deploy it with xulrunner 29.0.1 and thats when I am facing the problem. The mar auto-update thing seems not to be working across all the platforms. Once the mar-update is downloaded and I restart the application, the updates didn't get applied and when I went on to check the last-update.log, this is what I found: SOURCE DIRECTORY C:\Users\$USER$\AppData\Local\\.\\\updates\0 DESTINATION DIRECTORY C:\Program Files\infogridpacific\AZARDI DoUpdate: error extracting manifest file failed: 6 calling QuitProgressUI Does anyone know if there is any change in auto-update strategy after xulrunner 29.0 ? And is there any other solution to the above problem? Any help will be useful. Thanks in advance. ___ 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
UPDATE: Current action plan for try server issues
Thanks to a few hours of debugging by glandium Tuesday night, a tweak has been made which may address the multi-hour delays we had been seeing. (As of now, we've seen one successful push that took ~38 min of CPU and wall clock time to complete.) With that in place, the current plans are: a) right now we're monitoring for the impact (if any) of changes outlined in bug 1001735 comment 39 b) if there are any significant issues, we will perform a new history-preserving reset of try c) if there continue to be any significant issues, we will fall back to the old try reset which deletes history We have some confidence that (b) will be successful, and could be automated with minimal try closure time. I'll get a new bug open on that within a few days. --Hal On 2014-05-01, 11:26 , Hal Wine wrote: [including dev.platform this time as originally intended] tl;dr: there was a 4h outage on Wed, here's our plan if it happens again. Active bug for next reset: bug 1001735 (https://bugzil.la/1001735) Action Summary: - if we get another multi-hour (2) outage, we will immediately do a hard reset of try during business hours. - in parallel, we are looking at several history preserving methods for try resets - we will announce any hard reset here, along with the status of history. - we will announce any updates to this plan here Details: - many devs had timeouts on push to try - nothing landed on try for a 4h period, between Wed Apr 30 18:55:32 2014 + Wed Apr 30 23:05:24 2014 + - try has been responsive since then. Please let me know if anyone has strong objections to the above. --Hal ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
FYI: [Planned Maintenance Notification] Tree closing maintenance window, Sat May 17, 0900-1600 PT
Original Message Subject:[Planned Maintenance Notification] Tree closing maintenance window Date: Thu, 15 May 2014 21:28:41 - From: notificati...@mozilla.com To: every...@mozilla.org Short Summary: Mozilla IT will have a tree closing maintenance window on Saturday, 5/17, from 0900 PDT - 1600 PDT. During this window there will be some network maintenance, git.mozilla.org work, and upgrades to our load balancers to improve our services. Following is the work to be completed: 1004764 - Tracker bug 1004782 - firmware updates on git.mozilla.org and test failover 1008361 - reseat firewall card in SCL3 1007189 - maintenance and upgrades on data center load balancers (ZLB) Mozilla IT Outage Notification: -- Issue Status: Upcoming Bug IDs: 1004764 Start Date:2014-05-17 Start Time:09:00 PDT Site: SCL3 Services: Tree Closure, git.mozilla.org, bugzilla.mozilla.org, wiki.mozilla.org, blog.mozilla.org, mozillians.org, crash-stats.mozilla.com Impact of Work:During the window, the development trees will be closed. In addition, there may be brief periods of instability across multiple sites and services as the load balancer work is done. If you have any questions or concerns please address them to incide...@mozilla.com -- Mozilla IT - notificati...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed changes to autocomplete administrative levels
On 5/15/14, 8:21 AM, Ehsan Akhgari wrote: On 2014-05-15, 5:29 AM, Anne van Kesteren wrote: On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson bnichol...@mozilla.com wrote: If we disagree with this proposal: What alternatives do we have? Given that countries require more than two administrative levels in postal address, it seems our options are limited. We can't simply provide a single blob for an entire address as sites generally require more tokenized information. You do not want to tie this to a particular localization. E.g. I use the en-US version of Firefox, but I make payments with European credit cards. Localization should not affect functionality. Yes, this should definitely be tied to the locale of the page not the UA. If you're referring to which fields to show in the requestAutocomplete (rAc) UI, the ideal plan IMO would be to tie it to the country the user chooses in their autocomplete profile in the browser. So if I choose China as the country, I will see the three (or soon four) levels of address fields required, whereas choosing USA will only have City and State. The field labels would be in the language of the UA but would be localized for the country chosen. Do you know if Chromium or any other projects have an open source version of this mapping that we can use at least as a baseline? If you are referring to the localized names for all of the level fields in each region, then I don't know about such a mapping but I haven't looked for one. I believe Chromium is planning on using libaddressinput (that Brian linked to) in order to know which fields are required and the proper order. Unfortunately it only supports two address levels at the moment though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
