question about implementing infinitely-repeated instructions in aLogo implementation

I'm building a simple implementation of Logo in Scheme. I've built the
basics of turtle graphics, and am at the point of adding in multiple
turtles and thinking about how to have these turtles perform repeated
instructions. This raises 2 questions, which I'm hoping to get some
advice about.

My implementation basically takes a set of instructions, runs them,
then updates the graphics display and returns control to the user. If
I do something like:

to move
fd 10
move
end

with my implementation this will go into infinite recursion, never
update the screen, and never return control to the user. I notice that
for UCB Logo, if I run the same code, the screen is refreshed, but
control isn't returned (obviously).

My first question is, what is the preferred model for refreshing the
screen? My first thought is to redraw the screen buffer every time
there is any command which changes the display, but this seems
inefficient.

Secondly, I would like to be able to have the user start an infinitely
repeating set of instructions, but I would like the user to get back
to the input prompt. This would allow for starlogo-like continuous
behaviour of the turtles, but still allow the user to interactively
make changes. Does anyone have suggestions as to a good way to do
this?

thanks,
Alex

alex wrote:
> My first question is, what is the preferred model for refreshing the
> screen?

In aUCBLogo, there's an automatic screen update in the OnIdle handler,
plus just before a thread ends graph->update() is being called.
Additionally there's a primitive "updateGraph",
which allows the user to make a screen update when necessary.
There's also a primitive "setProcessIdleInterleaving",
which lets you control, how often the OnIdle handler is being called,
even if the machine is not idle,
default is for example at every 128th iteration of any Logo loop.
The automatic screen update can also be disabled,
by issuing the command "setUpdateGraph false",
which is nice if you want to draw hidden, and to only view the results,
so that you can make flicker-free animations.

> Secondly, I would like to be able to have the user start an infinitely
> repeating set of instructions, but I would like the user to get back
> to the input prompt. This would allow for starlogo-like continuous
> behaviour of the turtles, but still allow the user to interactively
> make changes. Does anyone have suggestions as to a good way to do
> this?

You can, like in aUCBLogo-4.8, start a new thread when the enter key in
the command line has been pressed.
But then you'll have to check before the execution of every Logo
command, if some definition has been changed.
This is done in aUCBLogo by watching if a "generation" counter has
changed. If true, the currently running procedure will be reparsed,
and it is tried to find the current line in the reparsed procedure.
If the search succeeds, the new code will be run,
else the old code runs still.

This allows, if using autoload mode, to edit running programs,
which can be very useful to produce instantaneous response to program
changes. For example in a curve fitting Logo program that I recently
wrote, it is very nice to just change a value of a parameter in the
program while the curve is being drawn.
Moreover, it is possible to add some other instructions to the code
during runtime, like a marker line, or a "print c2".

One problem is, when you create all those threads,
every Logo console will have to remember, if there is a pending "to",
so that users can enter procedures in a usual way at the command line.
This problem is not yet resolved in the current aUCBLogo debug version.

The other problem is,
that if your thread prints something to the console,
either the cursor location must be remembered,
to print just in the section below the issued command.
If there have been entered more than one commands,
this can be pretty complicated,
because the sections can all grow unequally.
There are also some problems accessing the same console resource,
so you need mutexes.
I have not worked this fully out in aUCBLogo,
so I just use a new console for any parallel execution,
but it really would be nice
to allow more than one command in one console.

So far my ideas. ;-)

Cheers,
Andreas

alex <lexaay@gmail.com> writes:
>My first question is, what is the preferred model for refreshing the
>screen?

At a minimum, any user interaction (e.g., calling READLIST/READWORD/READCHAR)
should refresh. So should WAIT and MOUSEPOS. (The reason WAIT is in the
list is that it's sometimes used to pace an animation, as in
to glide :distance
repeat :distance [fd 1 wait 1]
end
..) So should sound generation (TONE).

If you're supporting multiple turtles, another consideration is keeping them
synchronized. That is, if you have a bunch of turtles starting out in the
same position but different headings, and you start them all moving outward,
it'd be good if they form a circle,

On the other hand, one way you can speed things up noticeably is not to
redraw the turtle shape itself (as opposed to the lines traced by the turtle)
until there's some interaction or pause. So it really depends on how your
users are using the turtles -- as pen holders, or as shape holders.

>Secondly, I would like to be able to have the user start an infinitely
>repeating set of instructions, but I would like the user to get back
>to the input prompt. This would allow for starlogo-like continuous
>behaviour of the turtles, but still allow the user to interactively
>make changes. Does anyone have suggestions as to a good way to do
>this?

The most obvious answer is an operating system thread per turtle, but
that doesn't easily allow for keeping the turtles synchronized. Since
you're doing it in Scheme, you might think about building your own threads
out of call/cc.

Hi Brian and Andreas,

Thanks for your replies, this is very useful. I've been basing my
implementation on UCB Logo, so I think I'll grab a copy of aUCBLogo
and have a look at how these issues are addressed.

thanks!
Alex

On May 29, 8:31 pm, b...@cs.berkeley.edu (Brian Harvey) wrote:
> alex <lex...@gmail.com> writes:
> >My first question is, what is the preferred model for refreshing the
> >screen?
>
> At a minimum, any user interaction (e.g., calling READLIST/READWORD/READCHAR)
> should refresh. So should WAIT and MOUSEPOS. (The reason WAIT is in the
> list is that it's sometimes used to pace an animation, as in
> to glide :distance
> repeat :distance [fd 1 wait 1]
> end
> .) So should sound generation (TONE).
>
> If you're supporting multiple turtles, another consideration is keeping them
> synchronized. That is, if you have a bunch of turtles starting out in the
> same position but different headings, and you start them all moving outward,
> it'd be good if they form a circle,
>
> On the other hand, one way you can speed things up noticeably is not to
> redraw the turtle shape itself (as opposed to the lines traced by the turtle)
> until there's some interaction or pause. So it really depends on how your
> users are using the turtles -- as pen holders, or as shape holders.
>
> >Secondly, I would like to be able to have the user start an infinitely
> >repeating set of instructions, but I would like the user to get back
> >to the input prompt. This would allow for starlogo-like continuous
> >behaviour of the turtles, but still allow the user to interactively
> >make changes. Does anyone have suggestions as to a good way to do
> >this?
>
> The most obvious answer is an operating system thread per turtle, but
> that doesn't easily allow for keeping the turtles synchronized. Since
> you're doing it in Scheme, you might think about building your own threads
> out of call/cc.