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

use forever bottom

Expand Messages
  • azevedolivia
    how doesn t a command forever exist, as I can simulate a command like this without using the buttons? thank you
    Message 1 of 9 , Sep 29, 2005
      how doesn't a command forever exist, as I can simulate a command like
      this without using the buttons?
      thank you
    • Josh Unterman
      you can use the command LOOP, but it s rarely needed. forever buttons are nice, because you can stop them by just pressing on them. if you use a LOOP
      Message 2 of 9 , Sep 30, 2005
        you can use the command LOOP, but it's rarely needed.
        forever buttons are nice, because you can stop them by just pressing on them.
        if you use a LOOP statement, make sure to have a condition at the beginning that you can use to stop it.



        [azevedolivia <livia@...>]
        > how doesn't a command forever exist, as I can simulate a command like
        > this without using the buttons?
        > thank you
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      • Josh Unterman
        and as long as you re doing that, i guess you should use a while loop instead. [Josh Unterman ]
        Message 3 of 9 , Sep 30, 2005
          and as long as you're doing that, i guess you should use a while loop instead.

          [Josh Unterman <junterman@...>]
          > you can use the command LOOP, but it's rarely needed.
          > forever buttons are nice, because you can stop them by just pressing on them.
          > if you use a LOOP statement, make sure to have a condition at the beginning that you can use to stop it.
          >
          >
          >
          > [azevedolivia <livia@...>]
          > > how doesn't a command forever exist, as I can simulate a command like
          > > this without using the buttons?
          > > thank you
          > >
          > >
          > >
          > >
          > >
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
        • James Steiner
          ... In NetLogo, there are five ways of causing a command (or user-defined procedure) to run repeatedly and continuously. A. Place the command in a button, make
          Message 4 of 9 , Sep 30, 2005
            > how doesn't a command forever exist,
            > as I can simulate a command like
            > this without using the buttons?

            In NetLogo, there are five ways of causing a command (or user-defined
            procedure) to run repeatedly and continuously.

            A. Place the command in a button, make the button a "forever" button,
            and depress the button. Note that if a seperate setup procedure must
            be run, setup must be run from a seperate button, or executed from the
            command center, or coded for one-time execution in the forever button.

            B. Place the command in a one-time button. wrap the command in a "loop
            [ ]" clause, or a very large "repeat n [ ]" clause, or a never-ending
            "while [ ] [ ]" clause. FOr example, "loop [ command ]". Press the
            button. The button will remain pressed while the command repeatedly
            executes.

            C. Add the user-defined procedure called "startup" to the model. The
            startup procedure is automatically executed by NetLogo when a model is
            loaded. IInclude the command in the "startup" procedure, inside a
            "loop" clause, like this:

            to startup
            loop [ command ]
            end

            This assumes that no seperate one-time setup is required prior to
            invoking the command. If setup is required, then setup shold be
            invoked prior to the loop.

            to startup
            setup
            loop [ command ]
            end

            D. In the command center, enter the statement "loop [ command ]"

            Note that several commands can be run in "parallel" this way.

            E. Create a *reporter* that invokes the command, then place the
            reporter inside a monitor control. The monitor will invoke the
            reporter a few times a second (or less), frequency depending on what
            else is happening at the time. The reporter must retun a value (of
            course) but that value can be 0, or an emptry string, "" or anything
            else. It is irrelevent.

            Note that code run in monitors may alter the view, but never causes
            the view display to update. If an updated display is desired, some
            additional actions are required.

            To activate the update of the view, do any of the following:

            i. Create a blank forever button. The button can be completely blank,
            only "forever" need be set (checked). While the button is "down" the
            view updates continously.

            This would create a "fake" forever button, in that while the button is
            down, the model appears to be running, and when the button is up, the
            model appears to be stopped. The illusion is better if the monitor
            does not change. The illusion is even better if the monitor is covered
            by other controls, such as a resized go button, a text box, or
            whatever.

            i. Create a blank one-time button. The button can be completely blank,
            BUT, at least one character must have been typed into the code area,
            then deleted again. Each time the button is pressed, the view updates
            once. If nothing was ever typed in the code field, the ability of the
            button to update the view is not activated.

            Of couse, any code, or comment can be placed in the buttons, and any
            display string can be provided, as desired.

            iii. Type at least a single interpretable statement in the command
            center and hit enter. Only whitespace characters is not sufficient.
            However, a single comment character (;) is enough. The view will
            update at least once, but will update continuously for as long as it
            takes for the statment(s) entered to execute. For example, the
            statement "wait 5" takes 5 seconds to execute (even though the command
            center is immediately ready to accept another command), during which
            the view will be updated continuously. The statement "wait 86400"
            takes 24 hours to execute. The statement "loop [ wait 5 ]" will run
            "forever."

            When a command center command is running in the background, it runs
            until finished, or until a run-stopping condition occurs. For example:
            using "Halt"; issuing a "stop" command in the command center;
            recompiling the code pane; or causing a runtime error, even in the
            command center. Note that a compile-time error in the command center
            will NOT stop the model or backgound commands.

            I know this is waaaay too much information, but I hope the extra is as
            interesting to the other NetLogo hackers out there as it is to me!

            Three of these methods do not require button pressing. One required
            command typing. The other two do not require any user input at all
            (unless view updates are desired). Both of these are sneaky, and one
            is *really* sneaky, and create the possibility of creating NetLogo
            malware.

            Note: I keep forgetting to ask that there be some sort of control on
            the use of "startup" procedures... for example, code running inside a
            startup procedure should not be allowed to run "file-delete" or
            "file-write" without confirmation, or something.

            ~~James
          • Jerry Balzano
            James - This technique you mention of creating a reporter that invokes a command, then placing the reporter inside a monitor, is really intriguing. Where have
            Message 5 of 9 , Oct 3, 2005
              James -

              This technique you mention of creating a reporter that invokes a command, then placing the reporter inside a monitor, is really intriguing.  Where have you had occasion to use it?  (Or did you just think it up?)  I'd love something concrete to help me think about its possibilities.

              Jerry 

              On Sep 30, 2005, at 2:41 PM, James Steiner wrote:

              Note that several commands can be run in "parallel" this way.


              E. Create a *reporter* that invokes the command, then place the

              reporter inside a monitor control. The monitor will invoke the

              reporter a few times a second (or less), frequency depending on what

              else is happening at the time. The reporter must retun a value (of

              course) but that value can be 0, or an emptry string, "" or anything

              else.


            • James Steiner
              ... Hi Jerry! I came up with the idea this summer while brainstorming ways to create a software virus, written in pure NetLogo (no extensions), that infects
              Message 6 of 9 , Oct 4, 2005
                On 10/3/05, Jerry Balzano <gjbalzano@...> wrote:
                > This technique you mention of creating a reporter that invokes a command,
                > then placing the reporter inside a monitor, is really intriguing. Where
                > have you had occasion to use it? (Or did you just think it up?) I'd love
                > something concrete to help me think about its possibilities.

                Hi Jerry!

                I came up with the idea this summer while brainstorming ways to create
                a software virus, written in pure NetLogo (no extensions), that
                infects NetLogo files. Since monitors start running as soon as the
                model is loaded, they seemed an obvious way to quietly force viral
                code to execute.

                Fortunately, NetLogo lacks certain features needed to make effective
                NetLogo viruses.

                So, I've never used it in a real model yet. I doubt there is a
                practical use for this technique, since a running model could more
                reliably do for itself any side-effect code that might be put in a
                monitor. Not to mention, writing functions with side-effects is a bad
                practice, in general ;) .

                Best,
                ~~James
              • Craig Brozefsky
                ... It can read and write files, what else is needed? -- Craig Brozefsky NetLogo Hacker Center for Connected
                Message 7 of 9 , Oct 4, 2005
                  James Steiner <gregortroll@...> writes:

                  > Fortunately, NetLogo lacks certain features needed to make effective
                  > NetLogo viruses.

                  It can read and write files, what else is needed?

                  --
                  Craig Brozefsky <craig@...>
                  NetLogo Hacker Center for Connected Learning
                  When the going gets weird, the weird turn pro. - H.S.T
                • James Steiner
                  ... Hi Craig! 1. A NetLogo model can not enumerate the files or folders in a folder.. Without the ability to enumerate files and folders, a NetLogo virus has
                  Message 8 of 9 , Oct 5, 2005
                    On 10/4/05, Craig Brozefsky <craig@...> wrote:
                    > James Steiner <gregortroll@...> writes:
                    >
                    > > Fortunately, NetLogo lacks certain features needed to make effective
                    > > NetLogo viruses.
                    >
                    > It can read and write files, what else is needed?

                    Hi Craig!

                    1. A NetLogo model can not enumerate the files or folders in a folder..

                    Without the ability to enumerate files and folders, a NetLogo virus
                    has no way to discover unknown files sharing its folder that it might
                    infect, nor can it scan the file system looking for files to infect.
                    It is limited to "well known" files and folders, or to brute-force
                    scanning.

                    2. A NetLogo model can not know the current folder, or its own folder
                    and filename.

                    Without this ability, a NetLogo virus has to start by guessing file
                    locations, or has to scan the entire file system. Also, if a virus can
                    know the path and filename of the current model, then it can open and
                    read additional viral code, or data, from the model file itself. For
                    example, some of the viral code could be hidden in the model file
                    itself using steganography. Perhaps encoded as trailing whitespace
                    characters or additonal comment characters, or as gibberish at the
                    tail end of the information tab, by selectively alternating the
                    capitalization.

                    Without these two features, a NetLogo virus is limited to infecting
                    well-known files in well-known locations. And it must contain a list
                    of these files and locations within its code, in the procedures pane.

                    So, one could concoct a virus that infects all the known models in the
                    models library, for example, but only by building that list into the
                    virus code. Such a virus would be rather bulky and obvious and be very
                    easy to defeat, and would be unable to, for example, infect the models
                    stored on a thumb-drive or web folder, from which it could spread to
                    other users.

                    3. NetLogo has no primitives to convert bewteen characters to character codes.

                    This last ability would make it easier to encode and compress the
                    viral code or data in secret places within the model file. It's gravy.

                    If these abilities exist in NetLogo now, I couldn't find them!

                    ~~James
                  • Craig Brozefsky
                    ... These two sound generally useful. Handling dirs and paths across platforms, while maintaining portability of files/resources named with strings makes it a
                    Message 9 of 9 , Oct 5, 2005
                      James Steiner <gregortroll@...> writes:

                      > On 10/4/05, Craig Brozefsky <craig@...> wrote:
                      >> James Steiner <gregortroll@...> writes:
                      >>
                      >> > Fortunately, NetLogo lacks certain features needed to make effective
                      >> > NetLogo viruses.
                      >>
                      >> It can read and write files, what else is needed?

                      > 1. A NetLogo model can not enumerate the files or folders in a folder..
                      >
                      > 2. A NetLogo model can not know the current folder, or its own folder
                      > and filename.

                      These two sound generally useful. Handling dirs and paths across
                      platforms, while maintaining portability of files/resources named with
                      strings makes it a bit complicated.

                      I'm having "logical pathname" flashbacks now, the horror, the horror!

                      --
                      Craig Brozefsky <craig@...>
                      NetLogo Hacker Center for Connected Learning
                      When the going gets weird, the weird turn pro. - H.S.T
                    Your message has been successfully submitted and would be delivered to recipients shortly.