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

Re: [peditors] pScript documentation question

Expand Messages
  • jahn-rentmeister@gmx.de
    To me the most confusing thing about pscripts is the different times and when they are synchronous: There is runtime, right now and last action . I worked
    Message 1 of 11 , Nov 6, 2005
    • 0 Attachment
      To me the most confusing thing about pscripts is the different times and
      when they are synchronous: There is runtime, right now and "last action".

      I worked with runtime and "right now", and my chief interest was
      synchronizing those two, because that means you can work inside the
      pscript (with ifGoTo and calculations) with the result of keypresses.
      The former lives at "right now", the latter only at runtime. Decisions
      have to be made "right now", but information is only available at
      runtime, which tends to be later. Synchronizing them solves this dilemma.

      It seems to me that calling a pscript in the runtime fashion
      synchronizes both times, but that is not well documented. The manual
      talks about "emptying" the event chain, but it is not clear if emptying
      means "discard the contents" or "wait until the contents have been
      processed". Discarding them is seldom useful, but waiting until they are
      processed means that one can then use the result of a regexp match or
      the contents of a text field for a branch inside the script (which leads
      to great power).

      So, when in doubt, insert something like

      /&script[@@continuation001@@]}{continuation001::

      into your script. (That, and wear sunscreen)

      Kind regards
      Jahn Rentmeister
    • Paul Nevai
      # To me the most confusing thing about pscripts is the different times and # when they are synchronous: There is runtime, right now and last action . # # I
      Message 2 of 11 , Nov 7, 2005
      • 0 Attachment
        # To me the most confusing thing about pscripts is the different times and
        # when they are synchronous: There is runtime, right now and "last action".
        #
        # I worked with runtime and "right now", and my chief interest was
        # synchronizing those two, because that means you can work inside the
        # pscript (with ifGoTo and calculations) with the result of keypresses.
        # The former lives at "right now", the latter only at runtime. Decisions
        # have to be made "right now", but information is only available at
        # runtime, which tends to be later. Synchronizing them solves this dilemma.
        #
        # It seems to me that calling a pscript in the runtime fashion
        # synchronizes both times, but that is not well documented. The manual
        # talks about "emptying" the event chain, but it is not clear if emptying
        # means "discard the contents" or "wait until the contents have been
        # processed". Discarding them is seldom useful, but waiting until they are
        # processed means that one can then use the result of a regexp match or
        # the contents of a text field for a branch inside the script (which leads
        # to great power).
        #
        # So, when in doubt, insert something like
        #
        # /&script[@@continuation001@@]}{continuation001::
        #
        # into your script. (That, and wear sunscreen)

        This is true BUT "right now" is faster.

        I know it's confusing. Believe me, it is equally confusing for me. It's due
        to the way the Palm OS operates. /Paul
      • Paul Nevai
        # I m currently struggling to wrap my mind around pScript. # # I m a Unix SysAdmin, so I m not exactly ignorant of scripting # languages, and a good chunk of
        Message 3 of 11 , Nov 7, 2005
        • 0 Attachment
          # I'm currently struggling to wrap my mind around pScript.
          #
          # I'm a Unix SysAdmin, so I'm not exactly ignorant of scripting
          # languages, and a good chunk of what I do involves scripting. Once I
          # understand that basic design of the script language, I can generally
          # make my way.

          The basic design? It's a scripting language adopted to an OS which is event
          driven with a miniature event-queue [10 items] with 2 additional queues:
          key-events and point-events. It is for an OS where much is undocumented and
          which is changing from hardware to hardware, and where there doesn't seem to
          be any intent on fixing bugs.

          In addition, it was written by an amateur programmer who loves all unix
          shells and their scripting nature and whose entire life almost literally is
          directed by /bin/sh and /bin/ksh scripts. Oh yes, I also love plain text
          files as opposed to html, rtf, etc. When I need formatting, I use TeX.

          # Pointers greatfully accepted. (And yes, I'm ransacking the Files
          # section of the pEditors Yahoo group.)

          I suggest to look at the examples in pedit's manual.

          I myself don't use too many scripts so I am not the right person to ask for
          examples. Almost all my scripts are /&launch[...] scripts.

          All=my=best, Paul
        • dmccunney
          ... Ahhh. Useful info. Thanks! ... Understood and annoying, but irrelevant to what I m looking for. ... I prefer plain text myself, and my *big* pet peeve is
          Message 4 of 11 , Nov 7, 2005
          • 0 Attachment
            On 11/7/05, Paul Nevai <nevai@...-state.edu> wrote:

            > # I'm currently struggling to wrap my mind around pScript.
            > #
            > # I'm a Unix SysAdmin, so I'm not exactly ignorant of scripting
            > # languages, and a good chunk of what I do involves scripting. Once I
            > # understand that basic design of the script language, I can generally
            > # make my way.
            >
            > The basic design? It's a scripting language adopted to an OS which is event
            > driven with a miniature event-queue [10 items] with 2 additional queues:
            > key-events and point-events.

            Ahhh. Useful info. Thanks!

            > It is for an OS where much is undocumented and which is changing from
            > hardware to hardware, and where there doesn't seem to be any intent on
            > fixing bugs.

            Understood and annoying, but irrelevant to what I'm looking for.

            > In addition, it was written by an amateur programmer who loves all unix
            > shells and their scripting nature and whose entire life almost literally is
            > directed by /bin/sh and /bin/ksh scripts. Oh yes, I also love plain text
            > files as opposed to html, rtf, etc. When I need formatting, I use TeX.

            I prefer plain text myself, and my *big* pet peeve is HTML format
            email. I've been thinking about how to create a filter that would
            send a bounce message to folks sending HTML mail, along the lines of
            "If you wish to email me, do so in plain text. HTML format mail is
            deleted unread." (I use Outlook, so it probably means resorting to
            VBScript... :-( )

            > # Pointers greatfully accepted. (And yes, I'm ransacking the Files
            > # section of the pEditors Yahoo group.)
            >
            > I suggest to look at the examples in pedit's manual.

            I am, time permitting.

            > I myself don't use too many scripts so I am not the right person to ask for
            > examples. Almost all my scripts are /&launch[...] scripts.

            No, but you wrote the language...

            I am assuming pScript is "Turing complete", and that I can read data
            from an external source, manipulate that data in various ways, and
            write that data out again, possibly to a different destination. I am
            further assuming it supports control structures that will let me do or
            not do an action based on various criteria, like a system event or the
            value of a variable. And I'm assuming that I can call PalmOS
            functions or other programs from pScript to perform actions, and that
            I can attach pScripts to buttons.

            Are these assumptions accurate?

            Thanks in advance.

            > All=my=best, Paul
            ______
            Dennis
          • Paul Nevai
            # I am assuming pScript is Turing complete , and that I can read data # from an external source, manipulate that data in various ways, and # write that data
            Message 5 of 11 , Nov 7, 2005
            • 0 Attachment
              # I am assuming pScript is "Turing complete", and that I can read data
              # from an external source, manipulate that data in various ways, and
              # write that data out again, possibly to a different destination. I am
              # further assuming it supports control structures that will let me do or
              # not do an action based on various criteria, like a system event or the
              # value of a variable. And I'm assuming that I can call PalmOS
              # functions or other programs from pScript to perform actions, and that
              # I can attach pScripts to buttons.
              #
              # Are these assumptions accurate?

              The answer is "yes" to almost all assumptions [as long as you don't meet a
              Palm OS bug]. The exception is "I can call PalmOS functions". Not really.
              Only those which are explicitly documented in pedit's manual.

              Basically, you can do practically anything with pScripting what you can
              achieve manually by tapping and typing + a bunch of other things.

              /Paul
            • dmccunney
              ... The PalmOS bug *bites* you!. You die. Denniskilled by a PalmOS bug ... that s fine, and what I expected. ... ______ Dennis
              Message 6 of 11 , Nov 7, 2005
              • 0 Attachment
                On 11/7/05, Paul Nevai <nevai@...-state.edu> wrote:
                > # I am assuming pScript is "Turing complete", and that I can read data
                > # from an external source, manipulate that data in various ways, and
                > # write that data out again, possibly to a different destination. I am
                > # further assuming it supports control structures that will let me do or
                > # not do an action based on various criteria, like a system event or the
                > # value of a variable. And I'm assuming that I can call PalmOS
                > # functions or other programs from pScript to perform actions, and that
                > # I can attach pScripts to buttons.
                > #
                > # Are these assumptions accurate?
                >
                > The answer is "yes" to almost all assumptions [as long as you don't meet a
                > Palm OS bug].

                "The PalmOS bug *bites* you!. You die.

                "Denniskilled by a PalmOS bug

                > The exception is "I can call PalmOS functions". Not really.
                > Only those which are explicitly documented in pedit's manual.

                that's fine, and what I expected.

                > Basically, you can do practically anything with pScripting what you can
                > achieve manually by tapping and typing + a bunch of other things.

                > /Paul
                ______
                Dennis
              • dmccunney
                Let s try this again, *finishing* before Sensing... ... The PalmOS bug *bites* you!. You die. Dennis killed by a PalmOS bug on level 5 of a
                Message 7 of 11 , Nov 7, 2005
                • 0 Attachment
                  Let's try this again, *finishing* before Sensing...

                  On 11/7/05, Paul Nevai <nevai@...-state.edu> wrote:

                  > # I am assuming pScript is "Turing complete", and that I can read data
                  > # from an external source, manipulate that data in various ways, and
                  > # write that data out again, possibly to a different destination. I am
                  > # further assuming it supports control structures that will let me do or
                  > # not do an action based on various criteria, like a system event or the
                  > # value of a variable. And I'm assuming that I can call PalmOS
                  > # functions or other programs from pScript to perform actions, and that
                  > # I can attach pScripts to buttons.
                  > #
                  > # Are these assumptions accurate?
                  >
                  > The answer is "yes" to almost all assumptions [as long as you don't meet a
                  > Palm OS bug].

                  "The PalmOS bug *bites* you!. You die."

                  "Dennis killed by a PalmOS bug on level 5 of a pScript"
                  :-)

                  > The exception is "I can call PalmOS functions". Not really.
                  > Only those which are explicitly documented in pedit's manual.

                  That's fine, and what I expected. I hardly thought pScript would
                  expose *all* PalmOS functions.

                  > Basically, you can do practically anything with pScripting what you can
                  > achieve manually by tapping and typing + a bunch of other things.

                  Also as expected. Thanks, Paul. That at least tells me pScript can
                  do the sort of things I'd like to do, even if *how* is not currently
                  obvious.

                  > /Paul
                  ______
                  Dennis
                • jahn-rentmeister@gmx.de
                  ... They are. A very common assumption in procedural programming languages is that you can use the result of an operation once that operation is completed.
                  Message 8 of 11 , Nov 8, 2005
                  • 0 Attachment
                    > I am assuming pScript is "Turing complete", and that I can read data
                    > from an external source, manipulate that data in various ways, and
                    > write that data out again, possibly to a different destination. I am
                    > further assuming it supports control structures that will let me do or
                    > not do an action based on various criteria, like a system event or the
                    > value of a variable. And I'm assuming that I can call PalmOS
                    > functions or other programs from pScript to perform actions, and that
                    > I can attach pScripts to buttons.
                    >
                    > Are these assumptions accurate?

                    They are.

                    A very common assumption in procedural programming languages is that you
                    can use the result of an operation once that operation is completed.

                    This assumption does not hold true in pscripts: The result of an
                    operation that does a regexp search and copies the result into the
                    clipboard is a clipboard with the regexp match. Yet, using /&mess@[$~]
                    will output the contents of the clipboard from the time of the start of
                    the script. This is because of the two different timelines your commands
                    are executed on.

                    -Jahn
                  • Paul Nevai
                    Hi Guys: This is just to tell you that I read every message but I might not respond to all on pScripting since sometimes some of you know it better than I. I
                    Message 9 of 11 , Nov 9, 2005
                    • 0 Attachment
                      Hi Guys:

                      This is just to tell you that I read every message but I might not respond to
                      all on pScripting since sometimes some of you know it better than I. I mean
                      it seriously. All=my=best, Paul

                      P.S. I am glad to see that pScripting works on the TX too. Apart from the
                      issues I mentioned, I am satisfied with the TX. However, today, all my
                      VersaMail e-mail was moved from the in-box to the trash [I didn't do it] and
                      much of my e-mail didn't get fully downloaded despite the 60Kb limit I
                      have. All my e-mail today was much less than that.
                    • Michael M. Rye
                      VersaMail is a pile of poo. I recommend SnapperMail. -- Mike ...... Original Message ....... On Wed, 09 Nov 2005 07:29:32 -0500 (EST) Paul Nevai ... to ...
                      Message 10 of 11 , Nov 9, 2005
                      • 0 Attachment
                        VersaMail is a pile of poo. I recommend SnapperMail.

                        --
                        Mike

                        ...... Original Message .......
                        On Wed, 09 Nov 2005 07:29:32 -0500 (EST) Paul Nevai
                        <nevai@...-state.edu> wrote:
                        >Hi Guys:
                        >
                        >This is just to tell you that I read every message but I might not respond
                        to
                        >all on pScripting since sometimes some of you know it better than I. I mean
                        >it seriously. All=my=best, Paul
                        >
                        >P.S. I am glad to see that pScripting works on the TX too. Apart from the
                        >issues I mentioned, I am satisfied with the TX. However, today, all my
                        >VersaMail e-mail was moved from the in-box to the trash [I didn't do it]
                        and
                        >much of my e-mail didn't get fully downloaded despite the 60Kb limit I
                        >have. All my e-mail today was much less than that.
                      Your message has been successfully submitted and would be delivered to recipients shortly.