The ES6 generators and iterators API is a little different from the one initially implemented in Firefox, which dates back to an earlier design. Update task.js to work with the new API, which can now be tested in the latest build of V8:

http://wingolog.org/archives/2013/05/08/generators-in-v8

We should hopefully start implementing the new generators API soon in SpiderMonkey as well, so that the new version of task.js can then be used.

The silly Wait abstraction is more or less just a non-standard name for promises. Change the API to use standard promises, ideally making it compatible with both jQuery and Dojo, if possible.

The current API docs are generated using some stupid hand-hacked scripts I have locally on my machine. We should choose a documentation generation tool and use that.

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

There's currently just one implicit scheduler. There should be a scheduler API so that you can implement different schedulers, but it should default to the standard scheduler.

Might be worth taking a look at the scheduler API being worked on here:

https://bugzilla.mozilla.org/show_bug.cgi?id=692420

The Task.prototype.join primitive is fail-fast with exceptions: if any task throws, all the tasks are killed and the exception propagates. Implement an alternative combinator that is fail-soft: if a task throws, simply detach it and continue waiting for a return value from another task. If all tasks throw, the result should throw a "no answer" error, possibly packaged up with all the exceptions that were caught.

Object-detect for Map to use in place of ObjectMap? Or maybe something better than a side table... I just don't really want observables to have to mutate observers.

Use a standard preprocessing tool to make task.js work in multiple environments.

update to the latest version!

Promises are a DOM (and soon ES) standard, and implemented in Firefox and Chrome (enabled by default in upcoming releases). Depending on RSVP adds an unnecessary overhead for the environments implementing standard Promises. Please only load RSVP when Promises are not provided by the platform!

(BTW: The issue list really needs some cleanup. ;-))

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

The task.dom.js file is just a stub. Fill this out with a more complete set of promise-ified DOM facilities.

(Depends on issue #12.)

I believe that Task.prototype.join will cause a deadlock if there are cyclic joins. Should we do eager cycle detection? Some sort of garbage collection?

When a task creates a subtask, it should keep a reference to the child task so that if the parent is cancelled, it can cancel its children.

The current logic for choosing the next task is to use Math.random(). Should this just deterministically choose the next in the array? Or should it use a better PRNG?

This should be factored out into different schedulers.

For prompt memory management, when a task dies, all its internals should probably be nulled out.

One of the libraries I recently played with for doing non-blocking I/O is called gevent from python community. The nice thing was you can have a completely readable synchronous code yet the run time was non-blocking and managed cooperative scheduling. The gevent library monkey patched some of the system API level calls like "opening a socket" for example. I was wondering if there is a place for an abstraction like that on top of task.js so that there is no yield statements in users code.

There should be a nice "ready" abstraction in task.dom.js that, similar to jQuery, abstracts the "start running when the page is ready" concept. This can serve as the "main" function of the main thread of a task.js application.

The task.js documentation indicates that compatibility with Promises/A, the predecessor of A+, is required. Will task.js be updated to require compatibility with A+?

I have a fairly rich build environment right now (webpack and babel), so it may be hard discovering where the source of error is specifically, but when I build my project while merely importing task.js, it breaks the browsers' environment and lodash comes back to me saying that Array is not a function. I will provide more data on this as needed.

Just like task.dom.js there should be a task.node.js file that wraps standard Node libraries with promise abstractions for working with task.js. These won't really be useable until there's a version of task.js that implements generators, but once V8 implements generators, Node's async I/O is another good use case for task.js.

(Depends on issue #12.)

Create either a custom scheduler-wrapper (which would depend on issue #1) to record all events, or a global recording mode with an on-off switch. Recording should be to a serializable "script" data structure.

(Depends on issue #1.)

Need a build process with optimized and minified source, probably based on Closure.

Create a deterministic replay scheduler, which takes a task-interleaving script and re-enacts it.

(Depends on issues #1 and #9).

In examples/finish.html there is a script referenced at lib/task.dom.js which is missing from the repo. I ran the example in Firefox and it was only able to output the following:

outer task waiting...
inner task working...
inner task finishing...

...However it doesn't seem like anything in the example code is depending on anything other then task.js

Can you please add some node.js examples (I assume this works great with node too)? Along the same lines, on your taskjs.org website, can you make it clear if/how to install via NPM?

npm install taskjs

?

Forcing clients to pause a task in a separate turn introduces the possibility that the task might be scheduled and executed before the pausing occurs.

Hi,
I think this library should be published on bower or npm, I can help adding a task runner (gulp or grunt), minify the code and ship it to bower and / or npm.
Let me know if this is something you want to accomplish.
Regards

I think its meant to say non-blocking where it says blocking-io

My promises implementation in task.js is not at all compliant with Promises/A{+}. It's funny, actually, I did this work before I understood why promises implicitly chain — and with task.js it doesn't really need them to chain. But my promises will not interoperate correctly with any popular promise libraries.

And anyway, task.js should do one thing and do it well… ;-) So we should just depend on RSVP instead of rolling our own promises.

With JS Proxy it should be possible to return a promise which would behave exactly same as a wrapped object

Please check out http://taskjs.org/. The information there doesn't seem related to task.js.

There's absolutely no reason a task function should have to be a generator function. As long as it produces an iterator object, that's all we should care about. I.e., it should be duck typed.

The website http://taskjs.org/ is not available:

This site can’t be reached
taskjs.org’s server DNS address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

It's not a typo in address - the Web Archive shows the previously available website:

• https://web.archive.org/web/20161117122506/http://taskjs.org:80/

Is the URL different now or is the website down temporarily?

Suggestion: Instead of

var xhr1 = makeXHR("foo.json",
                   function(txt) { foo = txt; success() },
                   function(err) { failure() });  // missing argument `err`?
var xhr2 = makeXHR("bar.json",
                   function(txt) { bar = txt; success() },
                   function(e) { failure(e) });

write

var xhr1 = makeXHR("foo.json",
                   function(txt) { foo = txt; success() },
                   failure);
var xhr2 = makeXHR("bar.json",
                   function(txt) { bar = txt; success() },
                   failure);

Currently Task.prototype.fulfill doesn't make sure that this is still alive.

Need to choose a testing framework and set up a test suite.