#10 How to stop reordering of procedures when saving.

[Manfred Zindel]

Oh ... my ticket sent yesterday has disappeared ... so I retry:

Hi,

I like programming in FMSLogo (2D of course, not 3D).

I write programs for test evaluation in schools to prepare for the entry into the professional world. For the rendering of test results I let the software create graphically designed intelligent documents which convert individual results into advisory text (complete colloquial sentences) and more.

FMSLogo has proven to be a very logical, complete and reliable programming system, and the results are well accepted by the young people and their teachers, trainers, and advisors..

I like to use many procedures which have hierarchical dependencies inside a framework of global data taken from local files, which are all in a project directory. Moreover I made some special procedures outside the internal namespace as tools for text and color handling which I load from an external file. All this works pretty well. The output is a double print page (DIN A3 landscape) with 400dpi. This exceeds the screen by far in both directions and yields nearly professional printing. Nevertheless downscaling to the screen is made while producing the results, which works really fast.

My problem is the following: Whenever I have added some new procedures into the huge collection, and I have saved them on file and reaload them later, the order of the procedures has been converted from the meaningful way I put it before into a meaningless alphabetical order. What for? It is not agreeable to be always hunting for displaced procedures which should better be near the places where they belong to due to their dependencies.

So how can I avoid this alphabetical reordering?

Best regards
Manfred

[David Costanzo]

the order of the procedures has been converted from the meaningful way I put it before into a meaningless alphabetical order. What for?

I don't think this behavior was designed, so much as it emerged from other design decisions. FMSLogo is based on MSWLogo, which is based on UCBLogo, which is based on scheme. Like scheme, FMSLogo is as much a programming environment as it is a programming language. Every procedure, variable, or property list you define goes into a global "workspace", whether its definition comes from a file, is typed directly into the commander, or generated programmatically. When you click "Edall", you're editing the entire workspace. The workspace has no inherent order, but rather than displaying the contents in random order, it sorts them into a well-defined order (better than nothing). The order is: procedures, variables, property lists, each alphabetical.

Nothing in the workspace is linked to any file. In FMSLogo, a file is not much more than a partial workspace that can be load into the workspace. When you LOAD a file, FMSLogo parses it, runs it, then discards the file. Anything at the "top scope" (between definitions) is RUN, then forgotten. That comment you put just before the procedure? Gone! If you LOAD a different file that defines a procedure with the same name, the procedure from the first file is replaced. If you define that procedure from the commander, it also replaces the existing procedure. The procedure definition doesn't belong to either file any more than it belongs to the commander.

I don't like this either and I do most of my serious Logo programming in an external editor.

So how can I avoid this alphabetical reordering?

I can think of three ways:

1. Use an external editor and only LOAD files in FMSLogo (never SAVE)

2. Use SAVEL to specify the procedures and file to save.

3. Instead of clicking "Edall", use WINDOWFILEEDIT. Here's a simple helper that illustrates the idea (there's lots of room for improvement).

TO MYEDIT
   ; Let the programmer pick the file to edit.
   ; Note that the filename is not LOCAL to prevent it from going
   ; out-of-scope by the time LOAD uses it below.  Instead we BURY it.
   MAKE "MYEDIT.lastfilename DIALOGFILEOPEN "*.lgo
   BURY NAMELIST "MYEDIT.lastfilename

   IF NOT EMPTY? :MYEDIT.lastfilename [
      ; Edit the file, then LOAD it when you're done.
      WINDOWFILEEDIT :MYEDIT.lastfilename [LOAD :MYEDIT.lastfilename]
   ]
END

This exceeds the screen by far in both directions and yields nearly professional printing. Nevertheless downscaling to the screen is made while producing the results, which works really fast.

You may already know this, but instead of having to scale your work down to FMSLogo's 1000x1000 screen surface, you can specify the size of the drawing surface on startup with the "-W" and "-H" command-parameters. Something like

   fmslogo.exe -W 10000 -H 10000

will give you 100x the drawing space.

If you want to get clever, you could have FMSLogo compute the desired size, then use SHELL to launch another FMSLogo with the width/height command-line parameters and BYE from the first FMSLogo.

[Manfred Zindel]

Hi,

thank you very much for your fast and inspiring answer. Based on these
new ideas I'll find an efficient solution and inform you of the results.
I think, I can stay inside the workarea philosophy (far away from what I
am used to in everyday development) without taking an external editor.
By the way - can you let me know, which external editor you would
recommend for use with FMSLogo?

Best regards
Manfred

Dr.-Ing. Manfred Zindel
Diplom-Mathematiker
mz@pbreport.de +49(0)176-34478812
Inhaber und Geschäftsführer
--
pbreport e.K.
Arbeitsgruppe für wissenschaftliche Evaluation
und Verlag - gegründet 2001
Sebastianstr. 43, 33178 Borchen (Dörenhagen)
HR Paderborn A 2466

Am 22.09.2020 um 02:34 schrieb David Costanzo:

the order of the procedures has been converted from the meaningful
way I put it before into a meaningless alphabetical order. What for?

I don't think this behavior was /designed/, so much as it /emerged/
from other design decisions. FMSLogo is based on MSWLogo, which is
based on UCBLogo, which is based on scheme. Like scheme, FMSLogo is as
much a programming environment as it is a programming language. Every
procedure, variable, or property list you define goes into a global
"workspace", whether its definition comes from a file, is typed
directly into the commander, or generated programmatically. When you
click "Edall", you're editing the entire workspace. The workspace has
no inherent order, but rather than displaying the contents in random
order, it sorts them into a well-defined order (better than nothing).
The order is: procedures, variables, property lists, each alphabetical.

Nothing in the workspace is linked to any file. In FMSLogo, a file is
not much more than a partial workspace that can be load into the
workspace. When you LOAD a file, FMSLogo parses it, runs it, then
discards the file. Anything at the "top scope" (between definitions)
is RUN, then forgotten. That comment you put just before the
procedure? Gone! If you LOAD a different file that defines a procedure
with the same name, the procedure from the first file is replaced. If
you define that procedure from the commander, it also replaces the
existing procedure. The procedure definition doesn't belong to either
file any more than it belongs to the commander.

I don't like this either and I do most of my serious Logo programming
in an external editor.

So how can I avoid this alphabetical reordering?

I can think of three ways:

1.

Use an external editor and only LOAD files in FMSLogo (never SAVE)

2.

Use SAVEL to specify the procedures and file to save.

3.

Instead of clicking "Edall", use WINDOWFILEEDIT. Here's a simple
helper that illustrates the idea (there's lots of room for
improvement).

TO MYEDIT
; Let the programmer pick the file to edit.
; Note that the filename is not LOCAL to prevent it from going
; out-of-scope by the time LOAD uses it below. Instead we BURY it.
MAKE "MYEDIT.lastfilename DIALOGFILEOPEN "*.lgo
BURY NAMELIST "MYEDIT.lastfilename

IF  NOT  EMPTY?  :MYEDIT.lastfilename  [
   ;  Edit  the  file,  then  LOAD  it  when  you're  done.
   WINDOWFILEEDIT  :MYEDIT.lastfilename  [LOAD  :MYEDIT.lastfilename]
]

END

This exceeds the screen by far in both directions and yields
nearly professional printing. Nevertheless downscaling to the
screen is made while producing the results, which works really fast.

You may already know this, but instead of having to scale your work
down to FMSLogo's 1000x1000 screen surface, you can specify the size
of the drawing surface on startup with the "-W" and "-H"
command-parameters. Something like

fmslogo.exe  -W  10000  -H  10000

will give you 100x the drawing space.

If you want to get clever, you could have FMSLogo compute the desired
size, then use SHELL to launch another FMSLogo with the width/height
command-line parameters and BYE from the first FMSLogo.

---

[support-requests:#10]
https://sourceforge.net/p/fmslogo/support-requests/10/ How to stop
reordering of procedures when saving.

Status: open
Group: GUI
Created: Mon Sep 21, 2020 10:11 AM UTC by Manfred Zindel
Last Updated: Mon Sep 21, 2020 10:11 AM UTC
Owner: David Costanzo

Oh ... my ticket sent yesterday has disappeared ... so I retry:

Hi,

I like programming in FMSLogo (2D of course, not 3D).

I write programs for test evaluation in schools to prepare for the
entry into the professional world. For the rendering of test results I
let the software create graphically designed intelligent documents
which convert individual results into advisory text (complete
colloquial sentences) and more.

FMSLogo has proven to be a very logical, complete and reliable
programming system, and the results are well accepted by the young
people and their teachers, trainers, and advisors..

I like to use many procedures which have hierarchical dependencies
inside a framework of global data taken from local files, which are
all in a project directory. Moreover I made some special procedures
outside the internal namespace as tools for text and color handling
which I load from an external file. All this works pretty well. The
output is a double print page (DIN A3 landscape) with 400dpi. This
exceeds the screen by far in both directions and yields nearly
professional printing. Nevertheless downscaling to the screen is made
while producing the results, which works really fast.

My problem is the following: Whenever I have added some new procedures
into the huge collection, and I have saved them on file and reaload
them later, the order of the procedures has been converted from the
meaningful way I put it before into a meaningless alphabetical order.
What for? It is not agreeable to be always hunting for displaced
procedures which should better be near the places where they belong to
due to their dependencies.

So how can I avoid this alphabetical reordering?

Best regards
Manfred

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/fmslogo/support-requests/10/
https://sourceforge.net/p/fmslogo/support-requests/10/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions/

[David Costanzo]

Manfred asks:

By the way - can you let me know, which external editor you would recommend for use with FMSLogo?

Sorry, I don't have any to recommend. I use XEmacs, mostly because it's what I used professionally for C/C++ at the time I started maintaining FMSLogo (when it was called MSWLogo). It was convenient to use one editor for both C/C++ and Logo, even though XEmacs doesn't have any built-in support for Logo. I've seen plugins for other editors for understanding the Logo syntax, but I forget which ones or where the plugins are.

I'd like to think that FMSLogo is the best editor for FMSLogo code, so if you can get option #3 (using WINDOWFILEEDIT) to work for you, that'd be good. It has syntax coloring, auto completion, and paren matching. It's not appropriate for me because the Logo programming I do today is writing regression tests for changes I make to the FMSLogo source code and I need to be able to recompile and restart FMSLogo without losing my editor state.