Thoughts on JS library to help with event driven paradigms

Discussion in 'Javascript' started by pedz, Jun 13, 2010.

  1. pedz

    pedz Guest

    I need either a

    1) new language
    2) new JS library
    3) both 1 and 2
    4) new way of thinking

    Given:

    > Prototype.js was written by people who don't know javascript for people
    > who don't know javascript. People who don't know javascript are not
    > the best source of advice on designing systems that use javascript.
    > -- Richard Cornford, cljs, <f806at$ail$1$>


    I thought I'd be brave and ask here rather than there.

    More and more in browsers the programming model is becoming event
    driven. Take a typical Ajax call. My personal thought process is
    something like:

    1) Send the Ajax request
    2) wait for it to get back
    3) dig out the piece I need
    4) send the next Ajax request
    5) wait for it to complete
    6) etc.

    The problem is that steps 2 and 5 are done by setting up call back
    handlers and so the result is that I do not get to "see" the list of
    steps.

    In today's particular adventure, I'm not doing Ajax requests but
    working with Web Workers which have the same event driven
    characteristic. I could maybe change my thinking to not mind this at
    all but then I tried hooking up JSpec as a testing framework and it
    all fell apart. JSpec at its root is very sequenctial. And I'm going
    to bump into this same problem almost everywhere I go.

    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.

    To start, the VSF has a "pc" and a list of "instructions". The pc
    starts at 0 and works forward. The instructions are calls to
    Javascript ... here is my first weakness ... "functions" ? (I hope
    thats right.)

    What little I've used JS (most of it via Prototype (blush)), I really
    like the bind and bindAsEventHandler so that I can get the "this" set
    like I want. So, I was going to allow the user to specify the value
    of "this" as well as a list of arguments to pass to the function.
    Each of these functions needs a way to get back to the VSF so it would
    either be passed as an argument or somehow accessable via the context.
    JSpec uses the "with" statement for this but I know that Crockford, in
    particular, dislikes the with statement.

    The details of how the interface to the functions works has a lot of
    options but in general, the idea is that a function can tell the VSF
    to not proceed to the next instruction. Instead the VSF would just
    exit
    (return). For example, each instruction could return true if the next
    instruction should be executed and false if not. I suppose it could
    be
    part of the instruction's specification.

    Lets say that an instruction starts an Ajax call. It would set its
    completion handler to call vsf.resume where vsf is an instance of a
    VSF which initiated the Ajax call. The instruction itself would
    return false or do whatever is needed to cause the VSF to not go to
    the next instruction.

    The call to vsf.resume picks up at the next instruction and continues.

    Added entry points to VFS would be to get and set "instance" variables
    (as Ruby calls them) and also to chain VSF's so that a stack of VSF's
    can be created.

    At this point, there is enough power to be dangerous. The user
    creates his VSF instances and specifies the list of instructions.
    Calls vsf.resume and off it goes.

    More power could be added by adding features like being able to muck
    with the PC, being able to "return" from the VSF. The other idea was
    to implant a list of objects with the connotation that the list of
    instructions would be executed once with each object. The
    possibilities expand rather quickly which is what brought up point #1
    way up at the start of this.

    Perhaps, as a second evolution to this, a DSL could be wrapped around
    it.

    Also, I've been thinking in "single threaded" terms but a VSF could
    have a parent concept perhaps called a VPS (Virtual Program Sequence)
    which is just a list of instructions. Then a VSF would be started
    from a VPS. The idea is that multiple instances of the same VPS could
    be running around making a mess of things all at the same time. This
    would introduce the need of locking, etc.

    But, you ask, what about JSpec? Well, it would need to be redone to
    use VSFs but I think the majority of it would work as is. And that is
    a
    major objective: to be able to retrofit existing programs to use VSFs
    with
    a minimum of effort.

    By now, I hope you get the gist of all this.

    I suppose my questions are:

    1) Has this already been done somewhere? It seems like a rather
    obvious place to come to. I've found a few "multithreaded javascript"
    attempts but the seem to be going about it the wrong way implementing
    particular solutions rather than a general solution.

    2) Any particular thing above cause your face to melt in fear?

    Thank you for your time,
    pedz
     
    pedz, Jun 13, 2010
    #1
    1. Advertising

  2. pedz

    David Mark Guest

    On Jun 13, 6:38 pm, pedz <> wrote:
    > I need either a
    >
    >  1) new language


    And why do you need a new language?

    >  2) new JS library


    A new JS library to do what?

    >  3) both 1 and 2
    >  4) new way of thinking


    #4 would be my guess. :)

    >
    > Given:
    >
    > > Prototype.js was written by people who don't know javascript for people
    > > who don't know javascript. People who don't know javascript are not
    > > the best source of advice on designing systems that use javascript.
    > >   -- Richard Cornford, cljs, <f806at$ail$1$>


    Yes, that's quite evident.

    >
    > I thought I'd be brave and ask here rather than there.


    Brave? Regardless, people who don't know JS are not the best people
    to ask about JS. ;)

    >
    > More and more in browsers the programming model is becoming event
    > driven.


    Do you mean reliant on asynchronous operations (e.g. XHR, SQL, etc.)?

    > Take a typical Ajax call.  My personal thought process is
    > something like:
    >
    >  1) Send the Ajax request
    >  2) wait for it to get back


    You don't have to wait for it to get back. The request object calls
    you when it is ready (or has given up).

    >  3) dig out the piece I need
    >  4) send the next Ajax request
    >  5) wait for it to complete
    >  6) etc.
    >
    > The problem is that steps 2 and 5 are done by setting up call back
    > handlers and so the result is that I do not get to "see" the list of
    > steps.


    So you would prefer to use synchronous XHR calls? Unfortunately, they
    are unusable as they block the browser UI. Of course, that didn't
    stop Dojo. :)

    >
    > In today's particular adventure, I'm not doing Ajax requests but
    > working with Web Workers which have the same event driven
    > characteristic.


    In other words, they call back asynchronously.

    > I could maybe change my thinking to not mind this at
    > all but then I tried hooking up JSpec as a testing framework and it
    > all fell apart.


    You are either using it incorrectly or it is unsuited to test browser
    scripts.

    > JSpec at its root is very sequenctial.  And I'm going
    > to bump into this same problem almost everywhere I go.


    It sounds as if the problem is JSpec.

    Patient: Doc, it hurts when I do this.
    Doctor: Don't do *that*.

    So find another testing framework.

    >
    > 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.


    You'd be hard-pressed to call it a thread as JS implementations are
    single-threaded.

    The term "context" has no meaning by itself. But add "execution" and
    it is well-defined in JS. Well, unless you are the Dojo authors.

    dojo.partial = function(/*Function|String*/method /*, ...*/){
    // summary:
    // similar to hitch() except that the scope object is left to be
    // whatever the execution context eventually becomes.

    Did they mean "scope" or "execution context"? Of course, the answer
    is neither. But they aren't alone in such foolishness. The - this -
    object is referred to as "scope" in virtually every blob of JS posted
    to the Web in the last decade. I thought it was humorous that the
    Dojo "experts" managed to refer to it as both "scope" and "execution
    context" in the same sentence. That's certainly raising the bar for
    confusion.

    > So, for now, I'm going to call it a VSF
    > for Virtual Stack Frame.


    Okay.

    >
    > To start, the VSF has a "pc" and a list of "instructions".  The pc
    > starts at 0 and works forward.  The instructions are calls to
    > Javascript ... here is my first weakness ... "functions" ?  (I hope
    > thats right.)


    Hard to say at this point.

    >
    > What little I've used JS (most of it via Prototype (blush)),


    We all make mistakes. Admitting them is the first step to recovery.

    > I really
    > like the bind and bindAsEventHandler so that I can get the "this" set
    > like I want.


    Yes! You aren't as clueless as you think (at least not in comparison
    to the authors of most "major" JS libraries).

    > So, I was going to allow the user to specify the value
    > of "this" as well as a list of arguments to pass to the function.


    Yes, I believe that is what Prototype calls "bind" (similar to
    Function.prototype.bind found in the latest incarnation of ES). Such
    a construct can be very useful.

    > Each of these functions needs a way to get back to the VSF so it would
    > either be passed as an argument or somehow accessable via the context.


    I imagine you mean scope.

    > JSpec uses the "with" statement for this but I know that Crockford, in
    > particular, dislikes the with statement.


    Nobody likes it (and for very good reasons), though I did notice it
    about a hundred lines in in my review of Dojo 1.4. They are rebels
    for sure. :)

    >
    > The details of how the interface to the functions works has a lot of
    > options but in general, the idea is that a function can tell the VSF
    > to not proceed to the next instruction.  Instead the VSF would just
    > exit
    > (return).


    It sounds like you want a unit testing framework that can handle test
    functions that do asynchronous operations. Such things are already
    out there. I wrote one over the winter for My Library. In short,
    every unit test function receives a callback function from the
    framework. When each test completes (synchronously or
    asynchronously), it calls that function. The callback function logs
    the result and calls the next test function in the queue.

    > For example, each instruction could return true if the next
    > instruction should be executed and false if not.  I suppose it could
    > be
    > part of the instruction's specification.


    Interesting take. If you return true/false to indicate synchronous/
    asynchronous, what will indicate success/failure? ISTM it would be
    much simpler to have every function use the callback.

    >
    > Lets say that an instruction starts an Ajax call.  It would set its
    > completion handler to call vsf.resume where vsf is an instance of a
    > VSF which initiated the Ajax call.


    Why not keep it simple, at least for starters? Why do you need any
    special "VSF" objects at all? And points off for using the term
    "instance" as it doesn't really apply to JS objects (despite the
    unfortunately named instanceof operator).

    > The instruction itself would
    > return false or do whatever is needed to cause the VSF to not go to
    > the next instruction.
    >
    > The call to vsf.resume picks up at the next instruction and continues.


    See what I mean? The root of your problem is that you are trying to
    envision and design a complicated system where a simple one would
    suffice. That's a recurring theme for JS projects of all shapes and
    sizes (particularly libraries).

    >
    > Added entry points to VFS would be to get and set "instance" variables
    > (as Ruby calls them)


    Never mind what Ruby calls them. Who is she anyway? :)

    > and also to chain VSF's so that a stack of VSF's
    > can be created.


    I don't see why you need one "VSF", let alone a stack of them.

    >
    > At this point, there is enough power to be dangerous.


    My thoughts exactly.

    > The user
    > creates his VSF instances and specifies the list of instructions.
    > Calls vsf.resume and off it goes.


    Calls resume to start? It's already confused and it isn't even off
    the drawing board.

    >
    > More power could be added by adding features like being able to muck
    > with the PC,


    Muck with the PC?

    > being able to "return" from the VSF.


    You return when the queue is empty, which happens after each of the
    queued tests has either completed or timed out. And to alleviate any
    confusion, the "queue" I refer to is just an array of test functions.

    > The other idea was
    > to implant a list of objects with the connotation that the list of
    > instructions would be executed once with each object.


    You should settle on one (preferably simple) idea to start with.

    > The
    > possibilities expand rather quickly which is what brought up point #1
    > way up at the start of this.


    You are simply over-thinking the problem.

    >
    > Perhaps, as a second evolution to this, a DSL could be wrapped around
    > it.


    You have to create something before it can evolve.

    >
    > Also, I've been thinking in "single threaded" terms but a VSF could
    > have a parent concept perhaps called a VPS (Virtual Program Sequence)
    > which is just a list of instructions.  Then a VSF would be started
    > from a VPS.  The idea is that multiple instances of the same VPS could
    > be running around making a mess of things all at the same time.)


    I think you are going to make a fine mess. :)

    > This
    > would introduce the need of locking, etc.


    So why introduce it?

    >
    > But, you ask, what about JSpec?


    What about it?

    > Well, it would need to be redone to
    > use VSFs but I think the majority of it would work as is.


    Whatever.

    > And that is
    > a
    > major objective: to be able to retrofit existing programs to use VSFs
    > with
    > a minimum of effort.


    Why?

    >
    > By now, I hope you get the gist of all this.


    Somewhat.

    >
    > I suppose my questions are:
    >
    > 1) Has this already been done somewhere?


    All of it?! No idea.

    > It seems like a rather
    > obvious place to come to.  I've found a few "multithreaded javascript"
    > attempts but the seem to be going about it the wrong way implementing
    > particular solutions rather than a general solution.


    I think you are barking up the wrong tree with that concept.

    >
    > 2) Any particular thing above cause your face to melt in fear?


    No, but I do feel a headache coming on. Perhaps somebody else can
    recommend an existing unit testing framework for JS. ISTM that's
    would be the best thing for you at this point. If you like it,
    perhaps you can copy and evolve it to fit your grand plans for stacked
    VSF's and multi-threaded JS.

    Best of luck to you!
     
    David Mark, Jun 14, 2010
    #2
    1. Advertising

  3. pedz wrote:

    > Given:
    >
    >> Prototype.js was written by people who don't know javascript for people
    >> who don't know javascript. People who don't know javascript are not
    >> the best source of advice on designing systems that use javascript.
    >> -- Richard Cornford, cljs, <f806at$ail$1$>


    You misquoted one of my signatures, and failed to provide attribution.

    > I thought I'd be brave and ask here rather than there.


    Good idea.

    > More and more in browsers the programming model is becoming event
    > driven.


    It has been event-driven ever since (DOM Level 0).

    > Take a typical Ajax call.


    There are no "Ajax call"s.

    > My personal thought process is something like:
    >
    > 1) Send the Ajax request


    There are no "Ajax request"s either. There are HTTP requests.

    > 2) wait for it to get back


    .... the HTTP response?

    > 3) dig out the piece I need
    > 4) send the next Ajax request
    > 5) wait for it to complete
    > 6) etc.


    OK, except of the terminology.

    > The problem is that steps 2 and 5 are done by setting up call back
    > handlers and so the result is that I do not get to "see" the list of
    > steps.


    What does this mean? What exactly do you want to achieve?

    > [snip problems with "JSpec"]
    > JSpec at its root is very sequenctial. And I'm going to bump into this
    > same problem almost everywhere I go.


    You have failed to describe the problem you have.

    > 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.


    Those who think they need to invent catchy or sopisticated sounding but
    undescriptive/misleading terms seldom know what they are doing. You appear
    to be among them.

    > To start, the VSF has a "pc" and a list of "instructions". The pc
    > starts at 0 and works forward. The instructions are calls to
    > Javascript ... here is my first weakness ... "functions" ? (I hope
    > thats right.)


    There is no "Javascript", but everything that can be invoked with a
    CallExpression in these langueges can reasonably be called a function at
    least. If that is a property of an object, it is a method, too.

    > What little I've used JS (most of it via Prototype (blush)),


    IOW, you have not used it at all. Sorry.

    > I really like the bind and bindAsEventHandler so that I can get the "this"
    > set like I want.


    You don't need (or want) bind() aso. for that.

    > So, I was going to allow the user to specify the value
    > of "this" as well as a list of arguments to pass to the function.


    Not a bad idea in itself. Function.prototype.apply() can take care of it.

    > [snip description for a solution]
    >
    > By now, I hope you get the gist of all this.


    You appear to be describing at great length a potentially wrong solution for
    a non-problem.

    > I suppose my questions are:
    >
    > 1) Has this already been done somewhere? It seems like a rather
    > obvious place to come to. I've found a few "multithreaded javascript"
    > attempts but the seem to be going about it the wrong way implementing
    > particular solutions rather than a general solution.


    A solution for what? Working around the shortcomings of a borken testing
    framework that cannot be suited to the task?

    > 2) Any particular thing above cause your face to melt in fear?


    No, but that does not mean it is any good.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jun 14, 2010
    #3
  4. On 6/13/2010 4:56 PM, David Mark wrote:
    > On Jun 13, 6:38 pm, pedz<> wrote:
    >> I need either a
    >>
    >> 1) new language

    >
    > And why do you need a new language?
    >
    >> 2) new JS library

    >
    > A new JS library to do what?
    >


    I wonder the same.

    [...]

    >>
    >> I suppose my questions are:
    >>
    >> 1) Has this already been done somewhere?

    >
    > All of it?! No idea.
    >


    YUI Test provides async testing. It's good, but has some disadvantages
    that have really bugged me. I added a lot of patches to my own copy but
    got tired of doing that. YUI team doesn't fix stuff as fast as I need it
    (usually takes about a year or so) and they don't take patches unless
    you go through their legal paperwork. NO thanks. I'll just patch it and
    go and I'll advise anyone to do the same; filing bugs on YUI is helpful
    for the authors it takes a long time to get a fix (if ever).

    I started on a testing framework that provides async testing
    functionality. It's essentially an event-driven tree. Tests don't
    complete in order, necessarily and you can have deferred segments, as in:

    testFudgeHasPecansWhenDone : function() {

    var hasPecans;
    fudge.setUpReq();
    this.waitForCondition(fudgeDone, deferred);

    function deferred() {
    Assert.that(hasPecans, Constraint.strictEquals(true));
    }
    function fudgeDone() {
    var hasPecans = !!fudge.getPecans();
    }
    }
    ....

    I'd like to represent it visually in an expandable tree as nested lists
    and where a test case fails, the cause of the failure; the test
    function, its error, and the error's stack trace are shown.

    There should also be a feature to rerun that one test, without having to
    rerun the entire test case.

    I planned to NUnit-style use constraints, as above, to make it easily
    extensible with your own constraints.

    Assert.that(myFunction, functionCallsAlert);


    Where Assert.that would take both arguments and call the second argument
    with the first argument, expecting exactly a true result.

    I've not gotten that far with it, but if you (or anyone) is interested
    in building on it, send a mail or post here.

    Regardless, I suggest answering the first two questions first. If you
    need a new language, the whole thing may be a total waste of time. I
    know why I unit test. I've been doing it for years and I am good at it;
    I just haven't finished my own test runner. I'd like to get paid to do
    that, actually.

    Garrett
     
    Garrett Smith, Jun 14, 2010
    #4
  5. On 6/13/2010 5:41 PM, Thomas 'PointedEars' Lahn wrote:
    > pedz wrote:
    >


    [...]

    >> [snip problems with "JSpec"]
    >> JSpec at its root is very sequenctial. And I'm going to bump into this
    >> same problem almost everywhere I go.

    >
    > You have failed to describe the problem you have.
    >


    I understood it as the problem is wanting to test async calls, but
    finding synchronous testing frameworks to fail at that. Did I get that
    right?

    [...]

    >> I really like the bind and bindAsEventHandler so that I can get the "this"
    >> set like I want.

    >
    > You don't need (or want) bind() aso. for that.
    >


    Nope. Moreover, using bind ubiquitiously to handle variable this is
    inelegant and inefficient.

    Garrett
     
    Garrett Smith, Jun 14, 2010
    #5
  6. pedz

    pedz Guest

    From my original post:

    > The problem is that steps 2 and 5 are done by setting up call back
    > handlers and so the result is that I do not get to "see" the list of
    > steps.


    Part of my original "I need" list was #4 -- perhaps I need to just
    think differently.

    But my problem is that I'd like to be able to follow the flow of a
    program using async events like I do other programs. I look down a
    list of statements and see the sequence of steps being taken.

    Granted, that is not necessary. I've just come to be use to it.

    Wouldn't be more intuitive if I could write:

    result = doSomeCall();
    if (result == good)
    beHappy();
    else
    beSad();

    where doSomeCall() starts an asynchronous sequence of steps and the
    end result is returned?
     
    pedz, Jun 14, 2010
    #6
  7. pedz wrote:

    > But my problem is that I'd like to be able to follow the flow of a
    > program using async events like I do other programs. I look down a
    > list of statements and see the sequence of steps being taken.
    >
    > Granted, that is not necessary. I've just come to be use to it.


    In that case I suggest you use the script consoles built into many browsers,
    tools like Firebug, other debuggers (set a breakpoint in the callback), or
    use a logging feature in the callback (which, again, is often provided as a
    built-in with console.log()).

    > Wouldn't be more intuitive if I could write:
    >
    > result = doSomeCall();
    > if (result == good)
    > beHappy();
    > else
    > beSad();
    >
    > where doSomeCall() starts an asynchronous sequence of steps and the
    > end result is returned?


    No, because "asynchronous" implies that the result may not yet be available
    when doSomeCall() returns.


    HTH

    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jun 14, 2010
    #7
  8. pedz

    Scott Sauyet Guest

    On Jun 13, 6:38 pm, 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. [ ... ]


    If I have it right, both David and Thomas were somewhat misdirected by
    your talk of the testing framework. You are not looking particularly
    to rewrite the testing framework but to create a tool that helps you
    make a list of possibly asynchronous calls look as much like a list of
    synchronous ones as possible, right?

    A don't know of a tool out there, but I can imagine the start to an
    interface to building one, but I get stuck very quickly at forks. How
    do you handle, say, an AJAX call (sorry Thomas!) that fails? Do you
    add conditionals? Do you then need loops? Are you already on your
    way then to a DSL?

    Putting that aside for the moment, 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();

    where the function labeled #1 above might look like this:

    function(data) {
    var theSeq = this;
    MyAjaxFunction({
    url: 'myScript.php',
    method: 'POST',
    postData: {a : data.a, b:data.b},
    success: function(results) {theSeq.next(results)},
    failure: function(error) {theSeq.abort()}
    })
    }

    Such a constructor would generate objects that have methods such as
    start, next, and abort. Each function in the sequence is called with
    "this" bound to the sequence itself. If the function returns true,
    then the next function is called immediately. Otherwise the sequence
    is paused until its "next" method is called. You could use a property
    of the sequence object to hold data that needs to be shared among the
    steps,

    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.

    --
    Scott
     
    Scott Sauyet, Jun 14, 2010
    #8
  9. Thomas 'PointedEars' Lahn wrote:

    > pedz wrote:
    >> Wouldn't be more intuitive if I could write:
    >>
    >> result = doSomeCall();
    >> if (result == good)
    >> beHappy();
    >> else
    >> beSad();
    >>
    >> where doSomeCall() starts an asynchronous sequence of steps and the
    >> end result is returned?

    >
    > No, because "asynchronous" implies that the result may not yet be
    > available when doSomeCall() returns.


    I think you might be looking for something like

    doSomeCall(beHappy, beSad);

    But that alone will not help with your "problem".


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jun 14, 2010
    #9
  10. pedz

    pedz Guest

    On Jun 13, 8:38 pm, Scott Sauyet <> wrote:
    > On Jun 13, 6:38 pm, 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. [ ... ]

    >
    > If I have it right, both David and Thomas were somewhat misdirected by
    > your talk of the testing framework.  You are not looking particularly
    > to rewrite the testing framework but to create a tool that helps you
    > make a list of possibly asynchronous calls look as much like a list of
    > synchronous ones as possible, right?
    >
    > A don't know of a tool out there, but I can imagine the start to an
    > interface to building one, but I get stuck very quickly at forks.  How
    > do you handle, say, an AJAX call (sorry Thomas!) that fails?  Do you
    > add conditionals?  Do you then need loops?  Are you already on your
    > way then to a DSL?
    >
    > Putting that aside for the moment, 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();
    >
    > where the function labeled #1 above might look like this:
    >
    >   function(data) {
    >     var theSeq = this;
    >     MyAjaxFunction({
    >       url: 'myScript.php',
    >       method: 'POST',
    >       postData: {a : data.a, b:data.b},
    >       success: function(results) {theSeq.next(results)},
    >       failure: function(error) {theSeq.abort()}
    >     })
    >   }
    >
    > Such a constructor would generate objects that have methods such as
    > start, next, and abort.  Each function in the sequence is called with
    > "this" bound to the sequence itself.  If the function returns true,
    > then the next function is called immediately.  Otherwise the sequence
    > is paused until its "next" method is called.  You could use a property
    > of the sequence object to hold data that needs to be shared among the
    > steps,
    >
    > 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.


    Thank you Scott... you helped a lot.

    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.

    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.

    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.
     
    pedz, Jun 14, 2010
    #10
  11. pedz

    Scott Sauyet Guest

    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
     
    Scott Sauyet, Jun 14, 2010
    #11
  12. pedz

    pedz Guest

    On Jun 14, 8:29 am, Scott Sauyet <> 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
     
    pedz, Jun 15, 2010
    #12
  13. pedz

    Scott Sauyet Guest

    pedz wrote:
    > On Jun 14, 8:29 am, Scott Sauyet <> 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
     
    Scott Sauyet, Jun 15, 2010
    #13
  14. pedz

    David Mark Guest

    On Jun 14, 10:24 pm, Scott Sauyet <> wrote:
    > pedz wrote:
    > > On Jun 14, 8:29 am, Scott Sauyet <> 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
     
    David Mark, Jun 15, 2010
    #14
  15. pedz

    pedz Guest

    On Jun 14, 9:24 pm, Scott Sauyet <> wrote:
    > pedz wrote:
    > > On Jun 14, 8:29 am, Scott Sauyet <> 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.
     
    pedz, Jun 15, 2010
    #15
  16. pedz

    Scott Sauyet Guest

    pedz wrote:
    > On Jun 14, 9:24 pm, Scott Sauyet <> wrote:
    >> pedz wrote:
    >>> On Jun 14, 8:29 am, Scott Sauyet <> wrote:
    >>>> pedz wrote:

    >> 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.


    Okay, I seriously underestimated your ambition. You're talking about
    more than a DSL even, essentially a new language to be implemented
    atop Javascript.

    > 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.


    It most likely is. It's just that the HTML5 spec is still-evolving,
    and I don't know how well the Web Worker stuff has settled down, nor
    how good the implementations are. I haven't had any need for them
    yet.

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

    >
    > Any pointers to specific libraries in this area would help.


    I don't have any links off-hand. But any test framework that allows
    asynchronous calls presumably needs some similar facility.

    Good luck,

    -- Scott
     
    Scott Sauyet, Jun 15, 2010
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jo Blow

    documents on differing paradigms

    Jo Blow, Dec 25, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    330
    Jo Blow
    Dec 25, 2004
  2. crichmon

    C++: 4 paradigms?

    crichmon, Jul 18, 2004, in forum: C++
    Replies:
    26
    Views:
    1,786
    White Wolf
    Aug 1, 2004
  3. Eli Bendersky

    Paradigms in implementation of counters

    Eli Bendersky, May 24, 2006, in forum: VHDL
    Replies:
    17
    Views:
    802
    Mike Treseler
    May 31, 2006
  4. fullposter
    Replies:
    8
    Views:
    309
    Travis Newbury
    Dec 14, 2006
  5. hemant
    Replies:
    10
    Views:
    247
    Jason Roelofs
    Dec 5, 2007
Loading...

Share This Page