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

Re: functional, but dysfunctional

Expand Messages
  • notetab_is_great
    Here s a shorter clip library that shows the complete problem, which I figured out by gradually moving all the pieces of the original failing clip into the
    Message 1 of 19 , Feb 2, 2007
    • 0 Attachment
      Here's a shorter clip library that shows the complete problem, which I
      figured out by gradually moving all the pieces of the original failing
      clip into the original working clip, and it was the very last thing
      that made it fail :(

      bar is pretty much the way it was, except I fixed the bug that made it
      only work once, and added a StatusShow prompt. It still works...
      invoke it, and it shows that it is waiting for data, go copy something
      into the Clipboard, and then it grabs it, and displays it.

      Now try bar2. It fails, in exactly the same manner the much longer
      clip failed... a beep on every copy to the Clipboard.

      So clearly there is some bug or limitation on nested Clips. Can
      someone point me to documentation that explains the limitations? Or,
      preferably, tells how to work around them?



      = V5 MultiLine NoSorting TabWidth=30

      H=OnClipboardChange
      ; do nothing, if there is no variable to set
      ^!if "^%p_GrabClip%" = "" end
      ; set the variable whose name is in %p_GrabClip%
      ^!Set %^%p_GrabClip%%=^$GetClipboard$
      ; so that the variable is only set once, and we go back to doing nothing
      ^!Set %p_GrabClip%=""

      H=bar
      ; test case for the above... wait for one Clipboard change
      ^!Set %var%=""
      ^!Set %p_GrabClip%=var
      ^!StatusShow Waiting for value
      :loopback
      ^!Delay 1
      ^!IfSame "^%var%" "" :loopback
      ; display the results. Looks good.
      ^!Info var=^%var%

      H=bar2
      ^!Clip bar
    • acummingsus
      or ^%EMPTY% AFAIK either of those works. IOW one or the other of those is not wrong (AFAIK). I myself might at times prefer ^%EMPTY% for readability.
      Message 2 of 19 , Feb 3, 2007
      • 0 Attachment
        "" or ^%EMPTY%

        AFAIK either of those works. IOW one or the other of those is not
        wrong (AFAIK). I myself might at times prefer ^%EMPTY% for readability.

        (Please forgive me further below for there is room for me to chop a
        teency bit and be more concise, succinct. But I'm out of time for
        editing. Most importantly it does convey the point).

        --- In ntb-clips@yahoogroups.com, "notetab_is_great" <perl@...> wrote:
        >
        > Here's a shorter clip library that shows the complete problem, which I
        > figured out by gradually moving all the pieces of the original failing
        > clip into the original working clip, and it was the very last thing
        > that made it fail :(
        >
        > bar is pretty much the way it was, except I fixed the bug that made it
        > only work once, and added a StatusShow prompt. It still works...
        > invoke it, and it shows that it is waiting for data, go copy something
        > into the Clipboard, and then it grabs it, and displays it.
        >
        > Now try bar2. It fails, in exactly the same manner the much longer
        > clip failed... a beep on every copy to the Clipboard.
        >
        > So clearly there is some bug or limitation on nested Clips.

        It may be in this case that it doesn't work via ^!Clip due to "you
        have a, another clip running whilst_also OnClipBoardChange has been
        activated".

        (IOW, *perhaps* you reached/exceeded its limit)

        It appears to me that an OnClipBoardChange clip feature is designed
        for "no other clip to be running whilst it is activated for
        OnClipBoardChange feature to work/do_its_thing".

        I called it a feature because I think it is more than just a clip, as
        in . . .

        I took a good look at two Notetab native clip libraries, FormatEmail
        and PasteClips

        In both of those, once the "start" clip is run, this start clip sets a
        variable to a true value -- but then the start clip has expired,
        ended. IOW "there is no clip whatsoever running now in the this
        library with an OnClipBoardChange clip in it".

        So, *no clip is running*.

        I think how it works is that any library that has an OnClipBoardChange
        clip in it, whenever this library becomes the "currently opened or
        currently active" library then Notetab recognizes "oh, we have
        OnClipBoardChange *feature* in this library" (so, Notetab turns on its
        "system level (at the OS level) event monitoring" in this case the
        specific event of whenever a change happens to the content of the
        Windows clipboard.

        The feature equates to, via the mentioned event monitoring, capability
        to launch a clip named OnClipBoardChange whenever the system level
        (Windows) event happens.

        My experience, just exactly like Harvey mentioned, Notetab runs clips
        in serial, one clip at a time.

        Your functional but dysfunctional was running two clips at once (or
        attempting to do so). AFAIK running two clips at once in Notetab is
        not supported.

        A way to avert the nuisance of it *always* activating/launching the
        OnClipBoardChange clip upon every clipboard change is to do like the
        two native libraries I mentioned -- they immediately end the
        OnClipBoardChange clip unless a value has been set to true (look at
        the first code line of each of the two mentioned native libs in their
        OnClipBoardChange clip)

        So, statusshow requires a running clip in order to statusshow.

        With OnClipBoardChange feature, there is no clip running. But,
        instead what is happening, at the system level a specific event
        monitoring is taking place. It's an event monitoring that, when (OS
        level or Windows) clipboard changes, (launches a clip) launches the
        OnClipBoardChange clip.

        So, it's just a clip named OnClipBoardChange that Notetab has
        capability to launch whenever this mentioned OS level event happens.

        The next code in a library works via bar2 (^!Clip bar2)

        = V5 MultiLine NoSorting TabWidth=30

        H="bar"
        ; test case for the above... wait for one Clipboard change
        ^!Set %CheckClipboard%=True
        ; now there's no clip running

        H="bar2"
        ^!Clip bar

        H="_do2clipbrd"
        ; display the results. Looks good.
        ^!Info ClipboardText is ^%ClipboardText%
        ; turn off (immediately kill) the OCBC clip
        ^!Set %CheckClipboard%=False

        H="_OnClipboardChange"
        ; end immediately unless finds that true value
        ^!IfFalse ^%CheckClipboard% End
        ; I myself would forget statusshow
        ; since it needs a running clip. This the
        ; OCBC clip has a very short run time
        ; ^!StatusShow Waiting for value
        ; set the variable
        ^!Set %ClipboardText%=^$GetClipboard$
        ; say hello from the launched ocbc clip
        ^!Info Hi_ocbc
        ^!Clip do2clipbrd
        ; --- end -----

        --
        Alan.
      • notetab_is_great
        Alan, Thanks for your response. I m glad to know that %^EMPTY% is for documentation or special purposes, but that can also do the job. ... Below is a
        Message 3 of 19 , Feb 3, 2007
        • 0 Attachment
          Alan,

          Thanks for your response. I'm glad to know that %^EMPTY% is for
          documentation or special purposes, but that "" can also do the job.


          > Your functional but dysfunctional was running two clips at once (or
          > attempting to do so). AFAIK running two clips at once in Notetab is
          > not supported.


          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.

          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?

          To show that it is nested clips, try the following sequence: Invoke
          in the sequence donothing1, donothing2, donothing3invoker, donothing4

          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 unnested
          Clip invocation :( That is a severe limitation on building modular code.


          > The next code in a library works via bar2 (^!Clip bar2)
          (clip code clipped)

          Yes, you've come up with an alternate scheme that works... but
          reworking it that way seems like it would require much more complexity
          for my complete application (my postings are just a small piece of my
          plans). I may have to go that route, though.


          Here's my demonstration of concurrent clips.


          = V5 MultiLine NoSorting TabWidth=30

          H=OnClipboardChange
          ; do nothing, if there is no variable to set
          ^!if "^%p_GrabClip%" = "" end
          ; set the variable whose name is in %p_GrabClip%
          ^!Set %^%p_GrabClip%%=^$GetClipboard$
          ; so that the variable is only set once, and we go back to doing nothing
          ^!Set %p_GrabClip%=""

          H=bar
          ; test case for the above... wait for one Clipboard change
          ^!Set %var%=""
          ^!Set %p_GrabClip%=var
          ^!StatusShow Waiting for value
          ^!Delay 1
          ^!IfSame "^%var%" "" Skip_-1
          ; display the results. Looks good.
          ^!Info var=^%var%

          H=bar2
          ^!Clip bar

          H=donothing1
          ; runs forever, until Ctrl+Alt terminates it
          ^!SetHintInfo Yep, I'm doing nothing 1
          ^!Delay 800
          ^!SetHintInfo Yep, I'm doing nothing 1
          ^!Delay 100

          H=donothing2
          ; runs forever, until Ctrl+Alt terminates it
          ^!SetHintInfo Yep, I'm doing nothing 2
          ^!Delay 600
          ^!SetHintInfo Yep, I'm doing nothing 2
          ^!Delay 100

          H=donothing3
          ; runs forever, until Ctrl+Alt terminates it
          ^!SetHintInfo Yep, I'm doing nothing 3
          ^!Delay 400
          ^!SetHintInfo Yep, I'm doing nothing 3
          ^!Delay 100

          H=donothing4
          ; runs forever, until Ctrl+Alt terminates it
          ^!SetHintInfo Yep, I'm doing nothing 4
          ^!Delay 100
          ^!SetHintInfo Yep, I'm doing nothing 4
          ^!Delay 100

          H=donothing3invoker
          ^!Clip donothing3
        • Alan
          (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
          Message 4 of 19 , Feb 3, 2007
          • 0 Attachment
            (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

            # 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").

            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.

            On Saturday 03 February 2007 00:53, notetab_is_great wrote:
            <snip>
            > 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.

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

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

            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.

            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.

            Instead, proceesing goes along here in linear fashion. ^!Clip merely
            *directs* the processing to what I call a child clip. Once processing is
            done/exhausted in that child clip then the processing returns/continues with
            the very next line after the ^!Clip line in the parent clip.

            I've no argument about "nested".

            But my point here is that ^!Clip clip_name is a way to have what I might
            call "parent and child *portions of the same clip*"

            IOW when ^!Clip is used, Notetab sees however many nested of these as one
            clip.

            (it's an alternative to having one great big huge clip -- IOW the ^!Clip
            divided up clips should be considered as overall they are the one great big
            huge clip because this is how Notetab treats/handles this scenario in fashion
            whereby "only one clip is running") -- as I said, it's a way to route the
            processing.

            So, ^!Clip is a way to section off or divide up processing tasks via "chunks"
            of code. Also, when used at multi levels of depth (grandparent, parent,
            child), ^!Clip can be used for levels of (I suppose "nested") depth so as for
            processing to only go down to the lower most levels only when certain
            circumstances are met.

            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.

            I've yet to discover how many levels deep of "nested" (multi levels useage of
            ^!Clip) are in it. In my trying to grasp it (the entirety of the library's
            operations) IOW for me to *map* (access the how of) (have a map for myself of
            what does what and when it does it along the way) how it does what it does, I
            formerly *got lost* at somewhere near 3 to 4 levels deep.

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

            And/or, maybe I've not yet experimented enough with ^!SetDebug ON ??

            (The C programming language has ctags for a programmer to help track/know what
            does what and when it does it along the way)

            <snip>
            > Here's my demonstration of concurrent clips.

            My term for it is: "simultaneously running" clips (as per your useage
            instructions for them that are quoted/enclosed up above in this email).
            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.

            > = V5 MultiLine NoSorting TabWidth=30
            >
            > H=OnClipboardChange
            > ; do nothing, if there is no variable to set
            > ^!if "^%p_GrabClip%" = "" end
            > ; set the variable whose name is in %p_GrabClip%
            > ^!Set %^%p_GrabClip%%=^$GetClipboard$
            > ; so that the variable is only set once, and we go back to doing nothing
            > ^!Set %p_GrabClip%=""
            >
            > H=bar
            > ; test case for the above... wait for one Clipboard change
            > ^!Set %var%=""
            > ^!Set %p_GrabClip%=var
            > ^!StatusShow Waiting for value
            > ^!Delay 1
            > ^!IfSame "^%var%" "" Skip_-1
            > ; display the results. Looks good.
            > ^!Info var=^%var%
            >
            > H=bar2
            > ^!Clip bar
            >
            > H=donothing1
            > ; runs forever, until Ctrl+Alt terminates it
            > ^!SetHintInfo Yep, I'm doing nothing 1
            > ^!Delay 800
            > ^!SetHintInfo Yep, I'm doing nothing 1
            > ^!Delay 100
            >
            > H=donothing2
            > ; runs forever, until Ctrl+Alt terminates it
            > ^!SetHintInfo Yep, I'm doing nothing 2
            > ^!Delay 600
            > ^!SetHintInfo Yep, I'm doing nothing 2
            > ^!Delay 100
            >
            > H=donothing3
            > ; runs forever, until Ctrl+Alt terminates it
            > ^!SetHintInfo Yep, I'm doing nothing 3
            > ^!Delay 400
            > ^!SetHintInfo Yep, I'm doing nothing 3
            > ^!Delay 100
            >
            > H=donothing4
            > ; runs forever, until Ctrl+Alt terminates it
            > ^!SetHintInfo Yep, I'm doing nothing 4
            > ^!Delay 100
            > ^!SetHintInfo Yep, I'm doing nothing 4
            > ^!Delay 100
            >
            > H=donothing3invoker
            > ^!Clip donothing3
            ; end

            --
            Alan.
          • hsavage
            ... WordWeb s definition of concurrent. concurrent = Occurring or operating at the same time Although you initialize these DoNothing? clips they are not
            Message 5 of 19 , Feb 3, 2007
            • 0 Attachment
              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.

              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.

              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.

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

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

              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.

              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.

              º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@...
            • 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 6 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 7 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 8 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 9 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 10 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.