The business of editing procedures within the LOGO workspace can
be done in a couple of ways. Last time the reader will recall that
we encountered something of a problem in that the procedure being
prepared to drive the 'clock' demon eneded up in the workspace
along with the startup file that had been previously loaded.
Editing a new procedure seemed to require that we first erase
everything else so as to provide a 'clean' environment for the new
job at hand. In doing that, we ended up killing all previous work
including some that would have been nice to have on hand (for me,
the CLS command that I invented for myself.)

It was our conclusion that what we really needed was a way of
tagging a group of existing objects in the workspace (procedures,
properties, reporters, or whatever) so as to be able to chase them
out if we wanted to. I still don't have an answer for that, but
there is always more than one way to skin a cat.

EDFILE "FILENAME

will take you into LOGO's online editor and there you can prepare
your new procedure in isolation from the LOGO workspace. We've
used the editor before, but never gave it any real attention.

EDFILE looks for the filename you give it on the currently logged
media. If it finds the file, it loads it into the editor. If it
does not, it creates it. Once your file is set up (either loaded
or initiated) you'll notice that the normal '?' prompt disappears,
and you're left with the blinking square type cursor. Go ahead
and type something. Press return, and type another line. Now
press Smartkey VI. Note the media activity. You're file is being
saved. It's about the easiest way of creating a disk file that I
know of. If you consult pages R210 and pages 8, 9 and 10 of the
ADAM LOGO manual, you can familiarize yourself with the functions
of the various special keys.

We'll not go into that. Suffice it to say that inside the LOGO
editor, you have a means of editing or preparing several
procedures at once. There are at least two major advantages in so
doing.

Editing a procedure within the LOGO workspace poses a limitation.
You can only work on one procedure at a time. Despite any planning
you might have done about various elements of your overall task
being part of this procedure or that, you might end up realizing
as you type the procedure in that what you are typing really
should be a separate function. Inside the workspace, there is
nothing to do under such circumstances but to close the procedure
and start again.

In the editor, however, you can add, delete, move and re-arrange
various items in whatever order you want. You can edit two or more
procedures simultaneously and you can re-arrange your logic
completely if you so wish. You can even include a set of
variables, values and properties in the file.

The other advantage is that your work is saved directly to disk
and not to the workspace. Now it exists in isolation from anything
else you might have in your workspace at the time, such as STARTUP
files, or other procedures you've been working on. It presents an
easy way of keeping things separate.

These are the advantages of the editor. It's there for your use
any time you load LOGO. It is not a wordprocessor. You cannot
centre text with it, or do block deletes or moves. It does not
provide line wrapping, and it's output is all in upper case.
While you can read your file with SmartWriter, you cannot import a
Smartwriter file into EDFILE. So there are these limitations.
However for the purpose it's intended for it's powerful enough and
very very handy.

Now let's move onto something else. Consider the following LOGO
program:

LOGO Program "SG" (for SEARCH GROUP)
March 10, 1995, by Ron Mitchell

TO SG
CLS
PR [INPUT SEARCH STRING]
PR [4 CHARACTERS ONLY]
PR []
MAKE "ST FIRST RL
MAKE "C FIRST :ST
MAKE "ST CHOP :ST
PR [START ADDRESS FOR]
PR [SEARCH?]
PR []
MAKE "ADS FIRST RL
CLS
SEARCH.1
END

TO SEARCH.3
PR [THIRD CHARACTER]
PR :ADS
CLS
MAKE "ST CHOP :ST
MAKE "V3 FIRST :ST
MAKE "ADS :ADS + 1
MAKE "C3 .EXAMINE :ADS
IF EQUALP CHAR :C3 :V3 [SEARCH.4] [MAKE "ADS :ADS + 1 SEARCH.1]
END

TO SEARCH.2
PR [SECOND LETTER]
PR :ADS
CLS
MAKE "C2 FIRST :ST
MAKE "ADS :ADS + 1
MAKE "V2 .EXAMINE :ADS
IF EQUALP CHAR :V2 :C2 [SEARCH.3] [MAKE "ADS :ADS + 1 SEARCH.1]
END

TO SEARCH.4
PR [4TH CHARACTER]
PR :ADS
CLS
MAKE "ST CHOP :ST
MAKE "V4 FIRST :ST
MAKE "ADS :ADS + 1
MAKE "C4 .EXAMINE :ADS
IF :V4 = CHAR :C4 [PR [STRING FOUND AT] PR :ADS - 4] [MAKE "ADS
:ADS + 1 SEARCH.1]
END

TO SEARCH.1
SETCURSOR [1 1]
RECYCLE
PR [SEARCHING 1ST LETTER]
SETCURSOR [12 12]
PR :ADS
MAKE "V .EXAMINE :ADS
IF EQUALP CHAR :V :C [SEARCH.2] [MAKE "ADS :ADS + 1 SEARCH.1]
END

TO CHOP :ST
IF EMPTYP :ST [OP []] [OP BUTFIRST :ST]
END

TO CLS
CS
HT
SETCURSOR [1 1]
CHANGE.COLOR 15 1
END

This LOGO program will find a string of 4 characters anywhere in
memory. The string must be 4 characters in length, no longer, no
shorter, and there is no error checking (yet). As you can see I'm
still trying to develop some tools for wandering around inside
ADAM's memory when with LOGO loaded to see how things are laid
out.

This program is excruciatingly slow. I'd entertain any suggestions
to improve that. If your going to embark on a long search, you
might as well leave your ADAM on all night and check it after a
good night's sleep. That might be possible, but unfortunately even
if you adopt that approach there will be another problem.

Because of LOGO's way of allocating memory, the space available
seems to be reduced each time the program goes through an
iteration. That may not actually be true, but that's the apparent
effect that I see. I've been able to extend the area of memory
that can be searched by introducing RECYCLES at several spots.
Even with this step, eventually the program siezes up. If you
restart it, you can carry on from where you left off, but it makes
continuous memory searches unattended more or less impossible.

Nonetheless, it's a start.

If you type SG, you will be prompted for a search string, and a
memory location at which to start. If you want a quick example of
the program's output, try searching for the word LOGO starting at
memory location 185. The program will start searching there, and
provide you with a continuous readout of what location it is
searching. When it finds your string at four contiguous memory
locations, it will flash and let you know what address the string
starts at.

What are we looking for? Well, as previously in other
installments, a couple of needles in the haystack.

1) Where does LOGO store a table of current objects in the
workspace?

2) Where are the values that set screen size?

There are probably easier ways to search for this kind of
information, but I'm just playing around, really. I have also
mounted a more serious attempt to find what I'm looking for by
porting the entire LOGO interpreter over to the CP/M side of the
house where I can use all sorts of nifty stuff such as SuperZAP
and Rich Surwillo's Z8E. The result hasn't been much better...yet.
The only notable discovery to date has been that LOGO primitives
are stored backwards, for whatever that's worth.

It's not clear just yet how much use all this hacking can be put
to. So far what we've got two rather crude utilities both of which
can no doubt be improved upon. There are two things beginning to
emerge that can be somewhat annoying, depending on the
application, and it's becomming more and more obvious why LOGO
isn't the language of choice amongst programmers despite the fact
that it has a more complete command set and greater control
over ADAM than SmartBASIC does. The lack of memory and speed of
processing are surfacing as real drawbacks for all except the most
rudimentary of tasks.

Of course, a good carpenter never blames his tools!