Re: Terminating xulrunner?
Wow. All this just as I'm trying to get XULRunner repaired and stabilized for good with automated tests. I put a lot of effort into reviving the damn thing, and I'm close to getting it working again on the Mac. (More to the point, I'm obsessed with getting it working on the Mac again - and I know I'm getting close. There are heartbeats, I'm telling you.) I'm willing to own XULRunner and actively maintain it. People on this thread know I've been an advocate for it, and that I've submitted several patches to bring it back. I have been working with XULRunner for two years. If you are going to kill XULRunner off entirely in favor of firefox -app, then do it, *get it over with*, and write a "XULRunner Considered Harmful" blog post on planet mozilla. I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Sunday, January 12, 2014 4:34:54 PM UTC-8, Mike Hommey wrote: > - We could include the xulrunner and xulrunner-stub executables as part > of firefox. xulrunner-stub is small and self-contained, and xulrunner > could be replaced by something that calls firefox -app. Or we could > make the firefox executable check under what name it's called and act > accordingly. As I stated earlier, if we get this going quickly, I have no long-term objection. That said, it's almost time for an ESR cycle on mozilla-central, and that is cause for concern. I'd like to get a clarified list of requirements for the Firefox SDK: * Will we support a stub executable? * Will we support an install-app capability in the SDK? * Will Mac SDK users be able to create .app files that actually work? * Will they have a XUL.framework in them? * Will we still publish headers, binary tools, etc. in a convenient package for component developers to use? * Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.) * Will we have automated regression tests run daily to make sure the SDK is still viable? * What obvious requirements am I missing from this list? * Can we get everything in place and make an ESR SDK as well? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Platform SDK: What do we really want it to be?
Hi, everyone. There's general consensus that we want to terminate XULRunner as a project and replace it with a Firefox Platform SDK (name to be determined). [1] However, what precisely we want that SDK to do, and to support, we haven't figured out yet. I recently submitted a bug and patch to copy the stub executable and application bundling script (install_app.py) from XULRunner to Firefox. Mike Hommey (glandium) thinks that's a bad idea. [2] His objection is that "that just makes it stay outdated each time browser/app/nsBrowserApp.cpp is changed, which is one of the many reasons we want to get rid of xulrunner." Okay, fine. I'm all in favor of doing things the right way instead of the fast, hacky way. I'm also willing (and with my bosses' backing, somewhat able) to put in the time necessary to implement the right way. Getting XULRunner into an actually-usable state took a lot of hacks anyway... So we have to figure out what we really want. What I propose is writing our Firefox Platform SDK requirements down. [3] I'll put a first draft together as soon as practical (probably this weekend or next). First, a "Where Do We Stand" section, expressing what we currently have, what SDK and XULRunner customers currently try to do and demand from the Platform SDK, and operating-system-specific issues we face. Second, a list of concise "What The Platform SDK Must Or Should Support" sentences to clearly define our requirements. Third, a "Owners' Vote" section where a group of contributors vote yea or nay on the second section as it stands on the date they last read it. Specific objections and commentary may be written afterward. Also, constructive edits anywhere in the document (in particular, clarifying requirements or adding important requirements that I missed) are welcome. The idea is to arrive at a clear consensus on requirements. Finally, while I want to get this done and done right, I don't want to spend an inordinate amount of time on getting the requirements done. External parties want a Firefox Platform SDK yesterday. Firefox 30 development just started on mozilla-central. I'd like to have these requirements drafted and finalized before Firefox 31 development starts. That gives us six weeks from now. [4] I think that's reasonable for a requirements document. As for delivery dates on the actual Firefox Platform SDK: I don't know. I had hoped to put the pieces together before Firefox 31 entered the Aurora channel, so that it could be part of the "extended service release" for the 2014-2015 year. Until we can clarify what we want, though, that's just a dream. We can't really estimate the work, and how long it'll take, until we have the requirements hammered out. Again, folks: I'm willing and able to put in the time to make this work. Not just for my prototype XML editor project, either: the company I work for has a vested interest in XULRunner and in upgrading our platform. This is important, and shouldn't be rushed... but it should be done as promptly as is practical. Alex Vincent software engineer, FileThis, Inc. author, Verbosio XML Editor prototype [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/o99wQZBjIJw [2] https://bugzilla.mozilla.org/show_bug.cgi?id=961936 [3] https://etherpad.mozilla.org/s5jInveqm5 [4] https://wiki.mozilla.org/RapidRelease/Calendar ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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: 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
> 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 Monday, May 19, 2014 11:19:33 AM UTC-7, Jason Orendorff wrote: > But I'm not the one you have to convince. Who is? :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
Current source code: http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/src/transactions/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Async Transaction Manager: needs home, reviewers
In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK (replacement for XULRunner) and addon infrastructure work. Part of that latter bit would be support for asynchronous file operations in the AddonManager. The file operations, however, have to be revertable in the face of an error. To support that (and for other needs), I've written an asynchronous transaction manager (ATM) module, modeled after Mozilla's own transaction manager code. It should be more than adequate for AddonManager: one transaction comprises multiple asynchronous actions in a microtask. I am looking for someone who's willing to review this code and to help me refine it for mozilla-central. The reviewer should understand asynchronous Promise operations, preferably the OS.File promises, and should be willing to learn about the existing editor/txmgr code we currently have. (Like the rest of the editor code, I believe txmgr is basically unowned right now. But it is actually a pretty good component!) I'm also looking for a place to put an AsyncTransactionManager in the source code, probably in toolkit/modules, I'm thinking. Here's how it currently works: * The module exports a PromiseAction constructor with do, undo, redo methods. Each method should be replaced by the caller with a method that returns a Promise object. A do() method represents executing the action for the first time. The undo() and redo() methods represent reversing and restoring the single asynchronous operation of do(), respectively. * A transaction is basically a sequence of PromiseAction objects. * The ATM provides a doTransaction() method. The arguments currently are: *# intent: A string describing the transaction as a whole. *# code: An arbitrary value, recommended as a flag for merging the transaction into the previous transaction. *# merge: A method of the new transaction object: to determine if a following transaction should be merged into the transaction. *# task: A generator function yielding several PromiseAction objects in sequence. The transaction object is built from these. Thus, the user doesn't need to pass in Transaction objects. * If a PromiseAction's do() method yields a Promise which is eventually rejected, this is treated as an abort, and the ATM attempts to roll back the transaction by calling each successful PromiseAction's undo() method, in reverse order. * Likewise, an aborted ATM.undoTransaction() call results in successfully undone PromiseAction instances having their redo() methods called in forward order. Similarly, an aborted redo() call results in undo() calls on PromiseAction objects, in reverse order. * The ATM provides undoTransaction() and redoTransaction() methods, that take no arguments. These undo and redo individual transactions. * While asynchronous operations on a transaction are underway, calls to the ATM's doTransaction(), undoTransaction() or redoTransaction() methods automatically throw an exception. * There is also support for listening to transaction manager events (["willExecute", "didExecute", "willAttemptMerge", "didAttemptMerge"], ["do", "undo", "redo"]). I have a test suite already written and passing in Jasmine code; I'm perfectly willing and capable to port the tests to xpcshell-tests. Alex Vincent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Saturday, November 1, 2014 12:50:24 PM UTC-7, Kyle Huey wrote: > On Sat, Nov 1, 2014 at 12:42 PM, wrote: > > The reviewer should understand asynchronous Promise operations, preferably > > the OS.File promises > > We shouldn't be landing new code that uses Promise.jsm in mozilla-central. > > - Kyle I understand and agree... right now my module uses Promise.jsm, but I'd think it trivial to convert that to native Promise objects. Task.jsm, though, still uses it, and the module I'm proposing relies on Task.jsm pretty heavily... Are there plans to break Task.jsm's dependency on Promise.jsm? If not, is that okay? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
On Sunday, November 2, 2014 11:45:52 AM UTC-8, David Rajchenbach-Teller wrote: > This looks like toolkit/ stuff. > If you can segment this in small patches, I can try and review it. > > Cheers, > David How small are we talking? Other than making the tests a separate patch, I'm not sure splitting the module up into smaller patches would be very helpful. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Async Transaction Manager: needs home, reviewers
https://bugzilla.mozilla.org/show_bug.cgi?id=1093480 Comment 0: I think I will break this patch up into several incremental patches: * Inline API documentation, errors and basic infrastructure (stack of transactions, PromiseAction, isInTransaction) * doTransaction * undoTransaction * redoTransaction * Transaction listeners * Merging transactions * Transaction metadata * Undo / redo stacks (getting, clearing) Each phase will have its own tests as well. On Sunday, November 2, 2014 11:45:52 AM UTC-8, David Rajchenbach-Teller wrote: > This looks like toolkit/ stuff. > If you can segment this in small patches, I can try and review it. > > Cheers, > David > > On 01/11/14 20:42, ajvinc...@gmail.com wrote: > > In a couple weeks I'll be doing some work on Firefox-as-a-platform-SDK > > (replacement for XULRunner) and addon infrastructure work. Part of that > > latter bit would be support for asynchronous file operations in the > > AddonManager. > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
