Prev: MS recommends "feature detection"
Next: FAQ Topic - How do I modify the content of the current page? (2010-06-14)
From: Scott Sauyet on 14 Jun 2010 09:29
pedz wrote:
> Scott Sauyet wrote:
>> pedz wrote:
>
>>> [ ... ]
>>> This got me thinking about a JS library which would create a thing.  I
>>> don't want to call it a "thread" nor a "context" because both of those
>>> terms have so much meaning.  So, for now, I'm going to call it a VSF
>>> for Virtual Stack Frame. [ ... ]

>> [ ... ] would an interface like the implied Sequencer in the
>> following meet your requirements?
>
>>   var sequence = new Sequence(
>>     function() {/* set up AJAX call */},
>>     function() {/* perform AJAX call 1 */}, // #1
>>     function() {/* update DOM *},
>>     function() {/* perform AJAX call 2 */}
>>     function() {/* perform further DOM updates */}
>>   );
>>   sequence.start();
>> [ ... ]
>> Is that close to what you're looking for?  If so, it doesn't sound
>> particularly difficult to write.  But if you start talking about
>> branching or looping, it starts to sound more like language design,
>> like a much larger undertaking.
>
> Yes.  That is what I am talking about.
>
> As far as errors, the first step is to have all the handlers funnel
> back to a common point and that point returns a single "result".  Care
> would be needed for the case that two handlers fire but lets not go
> there yet.  Your approach of having a next and an abort I like too.

I'm not sure how the notion of handlers really fits with this model.
But as for simultaneous actions, all implementations of ECMAScript
I've used appear single-threaded. (I've heard that some versions of
Opera may differ, but I've never noticed it.) Things simply don't
happen at the same time in this model.

> The most primitive control structure would be a "skip if" statement.
> This provides a crude but still fairly readable if/then/else
> structure.  The "skip if" would skip one statement if the condition is
> true.  The next statement is usually a "branch to error code" or
> "return error code up to the next higher level".  A DSL for more
> sophisticated loops could build on top of this simple structure.

I think even simpler for a first pass would be to have each step in
the sequence do it's own gate-keeping:

if (!this.data.condition1) return;
// ...

> One thing I thought about between posts is the Sequence needs a way to
> start with at least one input argument.  But, that could be done via
> the get and set interfaces to the "Sequence local" variables.

Sequence.start could not return any meaningful result from the entire
sequence: at best you would be able to define a callback to handle
it's result; sorry, but that's just the nature of asynchronous
processing. But start could be supplied an input parameter, and abort
could accept and supply error messages.

That would imply event handlers associated with the Sequence,
something like onCompete and onAbort. Is that what you meant above?

--
Scott
From: pedz on 14 Jun 2010 19:42
On Jun 14, 8:29 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> pedz wrote:
> > Scott Sauyet wrote:
> >> pedz wrote:
>
> >>> [ ... ]
> >>> This got me thinking about a JS library which would create a thing.  I
> >>> don't want to call it a "thread" nor a "context" because both of those
> >>> terms have so much meaning.  So, for now, I'm going to call it a VSF
> >>> for Virtual Stack Frame. [ ... ]
> >> [ ... ] would an interface like the implied Sequencer in the
> >> following meet your requirements?
>
> >>   var sequence = new Sequence(
> >>     function() {/* set up AJAX call */},
> >>     function() {/* perform AJAX call 1 */}, // #1
> >>     function() {/* update DOM *},
> >>     function() {/* perform AJAX call 2 */}
> >>     function() {/* perform further DOM updates */}
> >>   );
> >>   sequence.start();
> >> [ ... ]
> >> Is that close to what you're looking for?  If so, it doesn't sound
> >> particularly difficult to write.  But if you start talking about
> >> branching or looping, it starts to sound more like language design,
> >> like a much larger undertaking.
>
> > Yes.  That is what I am talking about.
>
> > As far as errors, the first step is to have all the handlers funnel
> > back to a common point and that point returns a single "result".  Care
> > would be needed for the case that two handlers fire but lets not go
> > there yet.  Your approach of having a next and an abort I like too.
>
> I'm not sure how the notion of handlers really fits with this model.
> But as for simultaneous actions, all implementations of ECMAScript
> I've used appear single-threaded.  (I've heard that some versions of
> Opera may differ, but I've never noticed it.)  Things simply don't
> happen at the same time in this model.

The end result of what I'm trying to do would be similar to pthreads;
it would implement the concept of threading on top of a single
threaded machine just like pthreads, before multi-CPU or multi-
threaded OSs, could cause a single process to look like multiple
threads. In truth, only one thread was running at a time.

The HTML5 spec defines that only one thread per <something> ...
"similar browsing contexts" I think is the term. But it also defines
that a web worker will be at least a separate thread but can be a
separate process.

>
> > The most primitive control structure would be a "skip if" statement.
> > This provides a crude but still fairly readable if/then/else
> > structure.  The "skip if" would skip one statement if the condition is
> > true.  The next statement is usually a "branch to error code" or
> > "return error code up to the next higher level".  A DSL for more
> > sophisticated loops could build on top of this simple structure.
>
> I think even simpler for a first pass would be to have each step in
> the sequence do it's own gate-keeping:
>
>     if (!this.data.condition1) return;
>     // ...
>
> > One thing I thought about between posts is the Sequence needs a way to
> > start with at least one input argument.  But, that could be done via
> > the get and set interfaces to the "Sequence local" variables.
>
> Sequence.start could not return any meaningful result from the entire
> sequence: at best you would be able to define a callback to handle
> it's result; sorry, but that's just the nature of asynchronous
> processing.  But start could be supplied an input parameter, and abort
> could accept and supply error messages.
>
> That would imply event handlers associated with the Sequence,
> something like onCompete and onAbort.  Is that what you meant above?

I found "QUnit" which is JQuery's unit test framework. It has the
concept of "stopping" the test sequencing with an external call to
"start" to resume. It creates a queue of tasks and then runs through
them until "block" becomes true and then it exits. "start" turns off
block and then calls process to resume the execution. That has the
basic gist of what I was thinking about except it is limited to just
testing. I was hoping for a more general library.

Whether I keep going down this path, I'm not sure. Mostly it just
sounds fun. But the places where the javascript guys can help me is
with the lower level details.

For example, is "bind" a good idea or bad? What should be used
instead?

Thanks,
Perry

From: Scott Sauyet on 14 Jun 2010 22:24
pedz wrote:
> On Jun 14, 8:29 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
>> pedz wrote:
>>> As far as errors, the first step is to have all the handlers funnel
>>> back to a common point and that point returns a single "result".  Care
>>> would be needed for the case that two handlers fire but lets not go
>>> there yet.  Your approach of having a next and an abort I like too.
>
>> I'm not sure how the notion of handlers really fits with this model.
>> But as for simultaneous actions, all implementations of ECMAScript
>> I've used appear single-threaded.  (I've heard that some versions of
>> Opera may differ, but I've never noticed it.)  Things simply don't
>> happen at the same time in this model.
>
> The end result of what I'm trying to do would be similar to pthreads;
> it would implement the concept of threading on top of a single
> threaded machine just like pthreads, before multi-CPU or multi-
> threaded OSs, could cause a single process to look like multiple
> threads.  In truth, only one thread was running at a time.

I think a thread-scheduling algorithm for Javascript would be
extremely tricky. There is no real notion of suspending execution of
a function, only of scheduling the execution after a delay. Your code
would essentially have to manage the stopping and starting of
functions internally. It's not even clear to me what that would
mean...


> The HTML5 spec defines that only one thread per <something> ...
> "similar browsing contexts" I think is the term.  But it also defines
> that a web worker will be at least a separate thread but can be a
> separate process. [ ... ]

Have you used any implementations of this?


> I found "QUnit" which is JQuery's unit test framework.  It has the
> concept of "stopping" the test sequencing with an external call to
> "start" to resume.  It creates a queue of tasks and then runs through
> them until "block" becomes true and then it exits.  "start" turns off
> block and then calls process to resume the execution.  That has the
> basic gist of what I was thinking about except it is limited to just
> testing.  I was hoping for a more general library.

Yes, QUnit is similar, and any asynchronous testing toolkit probably
offers analogous capabilities.

> Whether I keep going down this path, I'm not sure.  Mostly it just
> sounds fun.  But the places where the javascript guys can help me is
> with the lower level details.
>
> For example, is "bind" a good idea or bad?  What should be used
> instead?

I think bind (called "hitch" in some systems) is pretty well essential
for complicated event-driven systems unless they are thoroughly object-
oriented, which I would not recommend for the Web.

--
Scott
From: David Mark on 14 Jun 2010 22:31
On Jun 14, 10:24 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> pedz wrote:
> > On Jun 14, 8:29 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> >> pedz wrote:
> >>> As far as errors, the first step is to have all the handlers funnel
> >>> back to a common point and that point returns a single "result".  Care
> >>> would be needed for the case that two handlers fire but lets not go
> >>> there yet.  Your approach of having a next and an abort I like too.
>
> >> I'm not sure how the notion of handlers really fits with this model.
> >> But as for simultaneous actions, all implementations of ECMAScript
> >> I've used appear single-threaded.  (I've heard that some versions of
> >> Opera may differ, but I've never noticed it.)  Things simply don't
> >> happen at the same time in this model.
>
> > The end result of what I'm trying to do would be similar to pthreads;
> > it would implement the concept of threading on top of a single
> > threaded machine just like pthreads, before multi-CPU or multi-
> > threaded OSs, could cause a single process to look like multiple
> > threads.  In truth, only one thread was running at a time.
>
> I think a thread-scheduling algorithm for Javascript would be
> extremely tricky.  There is no real notion of suspending execution of
> a function, only of scheduling the execution after a delay.  Your code
> would essentially have to manage the stopping and starting of
> functions internally.  It's not even clear to me what that would
> mean...
>
> > The HTML5 spec defines that only one thread per <something> ...
> > "similar browsing contexts" I think is the term.  But it also defines
> > that a web worker will be at least a separate thread but can be a
> > separate process. [ ... ]
>
> Have you used any implementations of this?
>
> > I found "QUnit" which is JQuery's unit test framework.  It has the
> > concept of "stopping" the test sequencing with an external call to
> > "start" to resume.  It creates a queue of tasks and then runs through
> > them until "block" becomes true and then it exits.  "start" turns off
> > block and then calls process to resume the execution.  That has the
> > basic gist of what I was thinking about except it is limited to just
> > testing.  I was hoping for a more general library.
>
> Yes, QUnit is similar, and any asynchronous testing toolkit probably
> offers analogous capabilities.
>
> > Whether I keep going down this path, I'm not sure.  Mostly it just
> > sounds fun.  But the places where the javascript guys can help me is
> > with the lower level details.
>
> > For example, is "bind" a good idea or bad?  What should be used
> > instead?
>
> I think bind (called "hitch" in some systems) is pretty well essential
> for complicated event-driven systems unless they are thoroughly object-
> oriented, which I would not recommend for the Web.

It's called "hitch" in Dojo, "delegate" in ExtJS and God knows what in
other libraries. Personally, I've never felt the need to encapsulate
call/apply in a function. However, per several requests, I recently
added a bind function that mimics the new Function.prototype.bind to
My Library (will be in the next build).

>
> --
> Scott

From: pedz on 15 Jun 2010 08:46
On Jun 14, 9:24 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> pedz wrote:
> > On Jun 14, 8:29 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote:
> >> pedz wrote:
> >>> As far as errors, the first step is to have all the handlers funnel
> >>> back to a common point and that point returns a single "result".  Care
> >>> would be needed for the case that two handlers fire but lets not go
> >>> there yet.  Your approach of having a next and an abort I like too.
>
> >> I'm not sure how the notion of handlers really fits with this model.
> >> But as for simultaneous actions, all implementations of ECMAScript
> >> I've used appear single-threaded.  (I've heard that some versions of
> >> Opera may differ, but I've never noticed it.)  Things simply don't
> >> happen at the same time in this model.
>
> > The end result of what I'm trying to do would be similar to pthreads;
> > it would implement the concept of threading on top of a single
> > threaded machine just like pthreads, before multi-CPU or multi-
> > threaded OSs, could cause a single process to look like multiple
> > threads.  In truth, only one thread was running at a time.
>
> I think a thread-scheduling algorithm for Javascript would be
> extremely tricky.  There is no real notion of suspending execution of
> a function, only of scheduling the execution after a delay.  Your code
> would essentially have to manage the stopping and starting of
> functions internally.  It's not even clear to me what that would
> mean.

Right. I can't actually do a context switch nor do I even want to.
The higher level code would likely break.

Remember what a program is -- all programs. Its a sequence of
instructions. Some instructions modify the PC. Some modify the
state. Thats it. On top of that is pile tons of sugar to make it so
that humans can program.

In this new paradigm, the "instruction" is a single javascript
function. The program fragments are lists of these instructions. The
PC is an index into this list. Any type of looping will be syntactic
sugar to modify this PC. The calls to create, as we called them,
"Sequence local" variables is what saves and retrieves the state.

All of that I'm comfortable with. I've been doing compilers and such
for many years. But to write a compiler, I need to talk to the chip
designers (or read their books). In this project I need to talk to
the Javascript guys.

> > The HTML5 spec defines that only one thread per <something> ...
> > "similar browsing contexts" I think is the term.  But it also defines
> > that a web worker will be at least a separate thread but can be a
> > separate process. [ ... ]
>
> Have you used any implementations of this?

Yes. That is what triggered this. I'm writing (as a self-tutorial)
what I guess is called a server-less web application. Its just a pile
of HTML and javascript. I have a "loader" and a "loader_worker" with
the loader_worker being in a web worker. The loader and loader_worker
talk back and forth via the message facility. It is asynchronous as
you might expect.

The original test rig using JSpec called the loader and then checked
to see if the load failed (it was a bad request to test the error
path) and the check was / is being done before the loader_worker would
communicate back to the loader that the request failed.

That doesn't really prove it is two separate threads I suppose but it
definitely appears as if it is.

>
> > I found "QUnit" which is JQuery's unit test framework.  It has the
> > concept of "stopping" the test sequencing with an external call to
> > "start" to resume.  It creates a queue of tasks and then runs through
> > them until "block" becomes true and then it exits.  "start" turns off
> > block and then calls process to resume the execution.  That has the
> > basic gist of what I was thinking about except it is limited to just
> > testing.  I was hoping for a more general library.
>
> Yes, QUnit is similar, and any asynchronous testing toolkit probably
> offers analogous capabilities.

Any pointers to specific libraries in this area would help.

>
> > Whether I keep going down this path, I'm not sure.  Mostly it just
> > sounds fun.  But the places where the javascript guys can help me is
> > with the lower level details.
>
> > For example, is "bind" a good idea or bad?  What should be used
> > instead?
>
> I think bind (called "hitch" in some systems) is pretty well essential
> for complicated event-driven systems unless they are thoroughly object-
> oriented, which I would not recommend for the Web.

Ok.

Thanks to all for helping out.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: MS recommends "feature detection"
Next: FAQ Topic - How do I modify the content of the current page? (2010-06-14)