Loading ...
Sorry, an error occurred while loading the content.

Re: functional, but dysfunctional also onclipboardchange and ^!clip

Expand Messages
  • notetab_is_great
    ... to convey a ... *launch* ... Commmunication is the hardest part about computers... knowing what the other fellow is saying so we comprehend and learn...
    Message 1 of 19 , Feb 3, 2007
    • 0 Attachment
      --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
      >
      > (There seems to be not yet achieved sufficient communication so as
      to convey a
      > correct understanding about the important distinction between 1. to
      *launch*
      > a 2nd (or 3rd, etc.) clip while a clip is already currently
      > running --*versus*-- 2. the use of ^!Clip


      Commmunication is the hardest part about computers... knowing what the
      other fellow is saying so we comprehend and learn...


      >
      > # 1 and # 2 are different. # 2 is *not* (not in actuality)
      *launching*
      > another clip while a clip is already running. Instead, what # 2 is
      doing is
      > it is "farming out" (or contracting to) (or, even better yet,
      "routing the
      > processing to").


      I think we agree on the difference between #1 and #2. #1, launching
      another clip while a clip is running, produces clips that appear to be
      running simultaneously. #2, using ^!Clip, which I call "nested
      clips", do not produce, and are not expected to produce, simultaneous
      execution: the ^!Clip operation suspends the first clips, performs the
      clip named as a parameter, and when that one completes, the first
      resumes at the next instruction.


      As far as I can determine, OnClipboardChange is a 2nd way, besides the
      user explicitly launching a clip, for a clip to be initiated. If
      other unnested-Clips are already running, it seems that
      OnClipboardChange can be successfully launched during ^!Delay
      operations in those other clips' operation sequence. But if any
      nested clip is currently running, then OnClipboardChange produces a
      beep, just like the user attempting to launch another clip while a
      nested clip is currently running.


      >
      > Continued further below is that ^!Clip, however many times it is
      used, is to
      > be seen as a conglomeration of clips that in actuality are
      esentially they
      > are united as one huge clip. The point is that, since ^!Clip is for
      "routing
      > the processing to", it is only one clip that is running no matter
      how many
      > times ^!Clip is used.


      When not thinking about simultaneous clips, your "united as one huge
      clip" comment is a reasonable interpretation of the matter, but when
      thinking about simultaneous clips, then there is a visible distinction.

      Initiation of donothing3 directly (one huge clip) does not prevent
      initiation of donothing4. Initiation of donothing3invoker, which has
      exactly the same set of operations as donothing3 because it calls it,
      does prevent initiation of donothing4, which proves there is a
      distinction between "one huge clip", and "united as one huge clip".



      > Are you trying to use clip as a programming language? It is not.
      It is a
      > macro language (a powerful macro language). Notetab is a text
      editor that
      > you can write clips/macros so as to "program (or automate repetitive
      tasks
      > in) the editor".


      In my computer science classes, I learned that a functional computer
      can be created from two instructions: subtract, and branch if
      negative. For example, negation can be synthesized by subtracting
      from 0, addition can be synthesized by negating and subtracting,
      multiplication is a series of additions, etc. So I find that NoteTab
      supports subtract [ ^!Set %x%=^$Calc(^%x%-^%y%)$ ] and branch if
      negative [ ^!If ^%x% < 0 Skip_-3 ], so I conclude that it is a
      programming language. To me, a macro language is simply a linear
      sequence of operations, like a tape recorder/player. Once control
      flow and arithmetic are added to a macro language, it becomes a
      programming language.


      > But clip itself is *definitely not* a programming language. A
      "programable
      > editor" is a term I've heard used about Notetab. But it is a macro
      language
      > that is used to achieve this automation or so called
      "programability" of the
      > editor.
      >
      > Oh, clip has likeness to, say, qbasic. I guess qbasic is considered
      as a
      > programming language. But clip is definitely macros language.
      > --


      So we disagree about what to call the clip language...


      > It *appears* to me that I've not yet *effectively* *totally*
      communicated
      > to/with you.
      >
      > I've no argument with you that your well made point quoted up
      > above "absolutely won't work".
      >
      > But, once again (as per your lib below) and your well made point
      quoted up
      > above, you are *launching* a second (and 3rd, etc.) clip while
      another clip
      > is still running. And, AFAIK when a clip is running, it is not
      supported to
      > *launch* a 2nd clip (nor a 3rd, etc.) so that now two clips are running
      > simultaneously.
      >
      > s/concurrently/simultaneously/; # perl substitution lingo
      >
      > I'm using the term "simultaneously" to replace or in place of
      concurrently
      > term that you used.
      >
      > AFAIK it is not supported in Notetab to launch/run two clips
      *simultaneously*.
      > That's not to say that sometimes it won't at least partially work or
      work
      > under some circumstances but not others.


      You likely have more experience with NoteTab/clip than I do, so I'm
      not going to disagree with anything you say here... but I would like
      to make some terminology definitions so we can communicate better.

      1) documented: a feature that is explained in the documentation.
      Generally all documented features are also supported (see below).

      2) supported: a feature that is claimed to work by the purveyor of the
      product. Generally all supported features are also documented, but
      sometimes older features, while still supported, are dropped from the
      documentation in favor of newer, better features that encompass all
      the capability of the older feature, and sometimes the documentation
      of new features lags the development of the feature and its delivery
      in the product.

      3) bonus: a feature that is not documented or supported, but which, by
      experimentation, is found to work. There is no guarantee that such a
      feature will work in future versions of the product.


      > A Very *Important* distinction: If by "nested" you mean what I call
      parent and
      > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
      > simultaneously running more than one clip at once.


      I agree; and that is why I was surprised to discover that nested
      clips, which you call parent/child clips, prevent the simultaneous
      invocation of other clips, whereas "one huge clip" does not, even if
      they have the same sequence of operations.


      > So as to illustrate the "nested" and "levels":
      >
      > Mr. Fookes, the author of Notetab, wrote the next clip library:
      >
      > http://www.notetab.com/pad/index.htm
      >
      > On that page, you can download the pad clip library. I
      suggest/offer that you
      > download that library and look at it.


      Yes, a very complex program.


      > I wonder if Mr. Fookes has something that we don't know about such
      as "tags"
      > for clips?


      Understanding such a complex program can often be better done by
      looking at the individual building blocks, and understanding them
      first... but I have no idea what tools Mr. Fookes might have for
      building clip libraries.


      > AFAIK, a *bonus* *if* it even works at all -- let alone whether or
      not it
      > works under more complex circumstances. AFAIK what's supported is
      only 1
      > clip running at a time, not 2 or 3 etc. clips launched and running
      at the
      > *same* time.


      So your theory is that simultaneous clips are a bonus feature.
      Certainly I couldn't find documentation for them, so they don't seem
      to be a documented feature.

      Yet Jody seems to write clips that use the feature, and so do others
      on this board. So it seems to be an acceptable use, perhaps it might
      be a supported feature, but it could be a well-used bonus feature.

      Can anyone declare that simultaneous clips are a bonus feature? What
      are the chances of them being removed, deprecated, or enhanced,
      respectively, in future version of NoteTab?

      If I build clips that depend on them, are they likely to continue working?

      Are there other limits that are likely to surface as clip complexity
      increases?
    • notetab_is_great
      ... I understand that it is extremely likely that multiple operating system threads/CPUs are not used to cause true concurrency. And I understand the how
      Message 2 of 19 , Feb 3, 2007
      • 0 Attachment
        --- In ntb-clips@yahoogroups.com, hsavage <hsavage@...> wrote:
        >
        >
        > notetab_is_great wrote:
        > >
        > > Below is a revised library that demonstrates up to 6 concurrent
        > > clips running: manually invoke, a few seconds apart, donothing1,
        > > donothing2, donothing3, and donothing4 in that order. Then invoke
        > > bar. Then put something on the clipboard. That is a total of 6
        > > clips running concurrently, and bar succeeds, providing that
        > > OnClipboardChange also succeeds. And watching the status bar long
        > > enough (90 seconds from when you started) will demonstrate that the
        > > other clips were still there, successfully.
        >
        > WordWeb's definition of concurrent.
        > concurrent = Occurring or operating at the same time
        >
        > Although you initialize these 'DoNothing?' clips they are not running
        > concurrently, they are running serially, in tandem, one after another.


        I understand that it is extremely likely that multiple operating
        system threads/CPUs are not used to cause true concurrency. And I
        understand the how multitasking on a single thread of control can be
        done. What I am trying to figure out is where the limits of
        multitasking are in the clip programming language.

        I understand that OnClipboardChange, ^!TimerPlay/^!TimerStart, and
        user invocation are the 3 asynchronous ways of initiating a clip. I
        understand that ^!Delay (and are there other such operations?) can
        suspend an unnested clip in such a manner that other clips can be
        invoked in a manner that appears like multitasking.


        > You can discover that by watching the NoteTab status line. The clips
        > will run 'last in, first out' order.
        >
        > The delays will time out in the last clip then the next most recent
        clip
        > will start timing.


        The delays seem to run concurrently. Check your watch from starting
        donothing1 until it completes, whether or not you invoke other
        donothingX clips in the meantime.


        > I believe if you tried this using language to do any actual work
        NoteTab
        > would 'Error' out. It isn't built for concurrent multi-tasking.


        I appreciate your response, and your experience with NoteTab, that has
        led you to your belief system about clips. I'm trying to get past
        belief systems, though, and understand exactly what capabilities are
        provided. It is documented that recursive clips are not supported.


        > > So it isn't the number of concurrent clips, but apparently
        > > something else, that causes the problems. My best guess so far is
        > > nested clips, but I suppose it could be something else. But why
        > > should nested clips cause more problem than concurrent clips?
        >
        > By 'nested' I suppose you mean clips that are started with a ^!Clip
        > command within the body of the currently running clip. If so, I use
        > nested clips all the time and have no trouble with them.


        Yes, that is what I mean by nested clips. And yes, they seem to work
        fine, when not also dealing with multitasking clips.

        But it seems that ^!Delay in a non-nested clip provides more ability
        to multitask clips than ^!Delay in a nested clip, which seems to block
        the ability to start another multitasking clip.


        > > Surprise! donothing4 won't invoke, it beeps. That is true even if
        > > OnClipboardChange is removed or renamed. So it seems that Delay
        > > only allows other clips to run if the Delay is invoked from an
        > > unrested Clip invocation :( That is a severe limitation on
        > > building modular code.
        >
        > I had no trouble with 'DoNothing4' beeping, it worked exactly like the
        > first 3 clips.


        I think you missed the difference in the two invocation sequences I
        was suggesting. Invoking donothing3 and then donothing4 works.
        Invoking donothing3invoker and then donothing4 beeps.


        > You may possibly be running into a dearth of resources, NoteTab
        requires
        > a lot of ram, some of the commands/functions are more ram intensive
        than
        > others.


        Only if NoteTab artificially limits the available resources. My
        machine is quite capable.


        > I thought I knew what you were striving for at one time, to use
        > 'OnClipBoardChange' and have an independent ^!StatusShow of an
        action to
        > be taken, but, I must admit I have no clue at this point.


        Yes, you did understand my goal. But my sample clips that have been
        posted are extremely limited, compared to my plans. When I discovered
        that nested clips and non-nested clips seem to differ in their ability
        to invoke ^!Delay and allow multitasking clips to be initiated, I
        created a sub-goal of attempting to understand the multitasking
        features of NoteTab in more depth, hopefully to discover if other such
        limits exist, before wasting a lot of time coding things that will not
        work.

        Presently, it appears that code must be structured so that ^!Delay
        operations are in non-nested clips, although nested clips can be
        called before or after the ^!Delay operation. This forces code to be
        designed differently than otherwise.

        Presently, it appears that OnClipboardChange, if it gets invoked at a
        time when all the multitasking clips are in non-nested ^!Delays, can
        successfully use as many nested clips of its own as it desires.

        Left to determine are whether there are other operations that wait for
        user input or timers (^!Delay waits for a timer, and if invoked from a
        nested clip, blocks multitasking clip initiation) that will block or
        otherwise confuse multitasking clips.

        >
        > ºvº SL-2-9
        > 2007.02.03 - 16.40.53
        >
        > Great Truth About Growing Old:
        > "Forget the health food. I need all the preservatives I can get."
        >
        > ¤ hrs ø hsavage@...
        >
      • Alan
        (I just saw your reply to Harvey - so I thought I d mention this it s the truth) BTW, my opining is based upon my experience of writing and using clips and
        Message 3 of 19 , Feb 3, 2007
        • 0 Attachment
          (I just saw your reply to Harvey - so I thought I'd mention this it's the
          truth) BTW, my "opining" is based upon my experience of writing and using
          clips and years of following this clips list and that I'm a very highly
          mechanical aptitude person. IOW, I choose not to believe the help file, and
          I "hack like crazy" and if I can make it work reliably then I'll use it. I
          certainly do not have firm belief systems of what I limit myself to that
          consists of what will and what will not work. To resolve something, I
          usually hack code until I get something to work (in addition to considering
          what others offer and considering the documentation/help).

          On Saturday 03 February 2007 15:32, notetab_is_great wrote:
          > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
          > > (There seems to be not yet achieved sufficient communication so as

          <snipped, 1. launch two clips in fashion whereby these two are "simultaneous
          execution/running versus 2. ^!Clip and how it operates.>

          > I think we agree on the difference between #1 and #2. #1, launching
          > another clip while a clip is running, produces clips that appear to be
          > running simultaneously. #2, using ^!Clip, which I call "nested
          > clips", do not produce, and are not expected to produce, simultaneous
          > execution: the ^!Clip operation suspends the first clips, performs the
          > clip named as a parameter, and when that one completes, the first
          > resumes at the next instruction.

          Yes.

          > As far as I can determine, OnClipboardChange is a 2nd way, besides the
          > user explicitly launching a clip, for a clip to be initiated.

          Yes.

          > If
          > other unnested-Clips are already running, it seems that
          > OnClipboardChange can be successfully launched during ^!Delay
          > operations in those other clips' operation sequence. But if any
          > nested clip is currently running, then OnClipboardChange produces a
          > beep, just like the user attempting to launch another clip while a
          > nested clip is currently running.

          This is where I opine (my useage of AFAIK) that it is a bonus if 2
          simultaneously execution/running clips might happen to work.

          <snipped "chunk (divided up pieces of) coding via the use of ^!Clip versus
          what I've opined as the alternative which is to have "one huge clip">

          > When not thinking about simultaneous clips, your "united as one huge
          > clip" comment is a reasonable interpretation of the matter, but when
          > thinking about simultaneous clips, then there is a visible distinction.
          >
          > Initiation of donothing3 directly (one huge clip) does not prevent
          > initiation of donothing4. Initiation of donothing3invoker, which has
          > exactly the same set of operations as donothing3 because it calls it,
          > does prevent initiation of donothing4, which proves there is a
          > distinction between "one huge clip", and "united as one huge clip".

          I've absolutely no argument with you whatsover about your call there on
          *distinction* . My point, however, is that I opine that such distinction
          exactly as that is attributed to an offshoot of that you are operating under
          a bonus condition and that the bonus is setting the stage for this to happen.

          Once again, I opine that this scenario you mentioned occurs in this fashion to
          you due to what I've termed/opined the bonus of if 2 simultaneous
          executed/running clips might happen to work.

          > In my computer science classes, I learned that a functional computer
          > can be created from two instructions: subtract, and branch if
          > negative. For example, negation can be synthesized by subtracting

          You lost me. Went over my head. That's ok.

          > So we disagree about what to call the clip language...

          Fine. All I know is I got it from Jody that to write a clip is to write a
          macro. And it appears that this came from Mr. Fookes to Jody though I've no
          absolute certainty of this latter.

          I suspect that there might be others who would agree with me. But I doubt
          that this matters. I only asked you because your coding style seemed to me
          to be "programmer like" ie the use of Notetab's perhaps a bit cursory multi
          level or variable within a variable syntax.

          > You likely have more experience with NoteTab/clip than I do, so I'm
          > not going to disagree with anything you say here... but I would like
          > to make some terminology definitions so we can communicate better.
          >
          > 1) documented: a feature that is explained in the documentation.
          > Generally all documented features are also supported (see below).
          >
          > 2) supported: a feature that is claimed to work by the purveyor of the
          > product. Generally all supported features are also documented, but
          > sometimes older features, while still supported, are dropped from the
          > documentation in favor of newer, better features that encompass all
          > the capability of the older feature, and sometimes the documentation
          > of new features lags the development of the feature and its delivery
          > in the product.
          >
          > 3) bonus: a feature that is not documented or supported, but which, by
          > experimentation, is found to work. There is no guarantee that such a
          > feature will work in future versions of the product.

          Agreed on all 3 with one exception. The exception is that (once again, I
          opine) that in some places the help/documentation is terse. And, it is
          enough so that people come to these lists asking for further and usually more
          specific of "in the help/doc, what does it mean by (thus_and_such)".

          > > A Very *Important* distinction: If by "nested" you mean what I call
          > > parent and
          > > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
          > > simultaneously running more than one clip at once.
          >
          > I agree; and that is why I was surprised to discover that nested
          > clips, which you call parent/child clips, prevent the simultaneous
          > invocation of other clips, whereas "one huge clip" does not, even if
          > they have the same sequence of operations.

          I opine, attribute this to being "in a so called bonus" sets the stage (bonus
          being the prelude to whatever)

          > So your theory is that simultaneous clips are a bonus feature.
          > Certainly I couldn't find documentation for them, so they don't seem
          > to be a documented feature.
          >
          > Yet Jody seems to write clips that use the feature, and so do others
          > on this board. So it seems to be an acceptable use, perhaps it might
          > be a supported feature, but it could be a well-used bonus feature.

          I myself have certainly not known that this is "well used"

          I would tend to think that it has not been used very much. I've not seen it
          in use very much if at all.

          One thing I do know, however, is that if it can work, people will use it.
          I've seen almost anything and everything. So, I'm not surprised that you
          have argument material against my mentioned herein opine of bonus.

          > Can anyone declare that simultaneous clips are a bonus feature? What
          > are the chances of them being removed, deprecated, or enhanced,
          > respectively, in future version of NoteTab?
          >
          > If I build clips that depend on them, are they likely to continue working?
          >
          > Are there other limits that are likely to surface as clip complexity
          > increases?

          notetab_is_great, I sincerely wish you good luck and happiness in all of your
          endeavors.

          --
          Alan.
        • notetab_is_great
          ... it s the ... using ... file, and ... it. I ... that ... considering ... Sounds like a good process to me :) But the documentation can be helpful (though
          Message 4 of 19 , Feb 3, 2007
          • 0 Attachment
            --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
            >
            > (I just saw your reply to Harvey - so I thought I'd mention this
            it's the
            > truth) BTW, my "opining" is based upon my experience of writing and
            using
            > clips and years of following this clips list and that I'm a very highly
            > mechanical aptitude person. IOW, I choose not to believe the help
            file, and
            > I "hack like crazy" and if I can make it work reliably then I'll use
            it. I
            > certainly do not have firm belief systems of what I limit myself to
            that
            > consists of what will and what will not work. To resolve something, I
            > usually hack code until I get something to work (in addition to
            considering
            > what others offer and considering the documentation/help).


            Sounds like a good process to me :) But the documentation can be
            helpful (though terse), in the areas in which it chooses to be. It is
            nice, for example, not to have to try strange combinations of
            characters after ^! to discover what operations are available...
            although maybe we could discover some great features that way!


            > > Yet Jody seems to write clips that use the feature, and so do others
            > > on this board. So it seems to be an acceptable use, perhaps it might
            > > be a supported feature, but it could be a well-used bonus feature.
            >
            > I myself have certainly not known that this is "well used"
            >
            > I would tend to think that it has not been used very much. I've not
            seen it
            > in use very much if at all.
            >
            > One thing I do know, however, is that if it can work, people will
            use it.
            > I've seen almost anything and everything. So, I'm not surprised
            that you
            > have argument material against my mentioned herein opine of bonus.


            Well, sometimes you see what you look for... it is hard to say how
            much use multitasking clips have gotten, but certainly it seems that
            they have gotten some use, because there is discussion about having
            clips that sit in the background and do things, and how to end them
            "typically by watching for Shift+Alt" and a couple coding conventions
            for detecting that combination.


            > > Can anyone declare that simultaneous clips are a bonus feature? What
            > > are the chances of them being removed, deprecated, or enhanced,
            > > respectively, in future version of NoteTab?
            > >
            > > If I build clips that depend on them, are they likely to continue
            working?
            > >
            > > Are there other limits that are likely to surface as clip complexity
            > > increases?
            >
            > notetab_is_great, I sincerely wish you good luck and happiness in
            all of your
            > endeavors.


            Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
            the forums, and comments. Seems the knowledge on this topic is quite
            limited (only a few responders, with only experimental knowledge (like
            mine, but mine is based on very limited experience so far))... so a
            few comments from Mr. Fookes might be extremely enlightening.
          • Alan
            ... ... I ve seen and contributed to posts/threads like that, searchable in the archives of this the ntb-clips list at Yahoo Groups. But most of them
            Message 5 of 19 , Feb 3, 2007
            • 0 Attachment
              On Saturday 03 February 2007 18:19, notetab_is_great wrote:
              > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
              <snip>
              > Well, sometimes you see what you look for... it is hard to say how
              > much use multitasking clips have gotten, but certainly it seems that
              > they have gotten some use, because there is discussion about having
              > clips that sit in the background and do things, and how to end them
              > "typically by watching for Shift+Alt" and a couple coding conventions
              > for detecting that combination.

              I've seen and contributed to posts/threads like that, searchable in the
              archives of this the ntb-clips list at Yahoo Groups.

              But most of them would be about how to put a clip into a repetitively looping
              mode while the user does something else, gathers what to input, or etc. And
              then using one of the control sequences of keyboard keys (you mentioned the
              shift+alt) (there are two others for a total of three available) to get the
              clip to do some action, either bring up a prompt for user input or resume
              processing somewhere or exit/end the clip. Outside of that, I'm not aware of
              any that loop repetitively, awaiting a signal of some sort so as to launch a
              2nd clip while this clip continues to run.

              > Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
              > the forums, and comments. Seems the knowledge on this topic is quite
              > limited (only a few responders, with only experimental knowledge (like
              > mine, but mine is based on very limited experience so far))... so a
              > few comments from Mr. Fookes might be extremely enlightening.

              AFAIK (there I go "opining" again). He's subscribed to this list or used to
              be anyways. I haven't seen much from him of late. Years ago he used to post
              more often on this list if you, for example, search the older archives of
              this list at Yahoo Groups.

              (login to the www yahoo groups first, and then,)

              Are you ready for nostalgia lane? Here goes:

              summer of 2001

              http://tech.groups.yahoo.com/group/ntb-clips/messages/7021?viscount=-30&l=1


              summer of 2000

              http://tech.groups.yahoo.com/group/ntb-clips/messages/4521?viscount=-30&l=1


              Feb. 2000 -- 3 posts on this page of Messages 2571 - 2600 of 16051

              http://tech.groups.yahoo.com/group/ntb-clips/messages/2600?viscount=-30&l=1

              Summer 1999

              http://tech.groups.yahoo.com/group/ntb-clips/messages/1200?viscount=-30&l=1

              March 1999
              http://tech.groups.yahoo.com/group/ntb-clips/messages/100?viscount=-30&l=1

              March 1999 Messages 1 - 30 of 16051
              http://tech.groups.yahoo.com/group/ntb-clips/messages/30?viscount=-30&l=1


              http://tech.groups.yahoo.com/group/ntb-clips/

              can go to there and scroll down to the message history for a profile of
              traffic related. It appears it has tapered off a slight bit over the last
              several years. Well, there's lots of archives to search now.

              Also I just ran across this, an faq by Jody:

              http://www.notetab.net/faq/ntb/index2.htm

              and a frames version of the same:

              http://www.notetab.net/faq/ntb/

              --
              Alan.
            Your message has been successfully submitted and would be delivered to recipients shortly.