This is a feature which worked fine on MSWLogo
but has been most frustrating in FMSLogo.
It is so important to me that I've developed several very crude work-arounds, but I'd prefer that the SHELL command work as it did in MSWLogo.
Since I wish to optimise learning from the past, I DRIBBLE every session to a file I call Harvey.log. My startup file does this.
A 2nd, and important part of this philosophy is to take the Harvey.log file from every session and append it to a file I call Harvey.hst, (History) which saves all of these files for posterity.
Implementing it under MSWLogo was relatively easy, and at one point
I had files with every keystroke I made at the Command prompt
for over 5 years. A gold mine for analysis.
This has NOT gone well in FMSLogo.
And all of the frustrations revolve around the SHELL command.
In MSWLogo it worked fine.
shell "C:\\Logos\\MSWLogo\\savelog.bat did it,
savelog.bat is simply:
copy Harvey.hst + Harvey.log Harvey.hst
Out of frustration, I moved this batch file to a desktop icon.
It works, but requires I remember to execute it every time I leave FMSLogo.
Being severly ADD, this is highly unreliable!
Here are some of my failed experiments.
Perhap some of you have ideas either to fix the commands,
or an entirely different way to achieve my desired results.
My goal is simply to append, each session's Harvey.log
to the cumulative file Harvey.hst (History)
Here is the directory structure which worked fine in MSWLogo.
The FMS main directory has the file Startup.lgo which is called from my desktop icon with the line:
"C:\Program Files\FMSLogo\fmslogo.exe" Startup.lgo
It works fine, loading my dynamic libraries from the subdirectory "buried'.
However when I add the single line, at the end:
SHOW (shell "savelog.bat 620)
I get the error msg "Unable to read file "startup.lgo from disk".
Because the file Startup.lgo drops to the subdirectory 'buried' to load all of my dynamic libraries, I thought perhaps if I added a POPDIR to get back to the main FMSLogo dir would help. It didn't, it made matters worse.
The error message was now:
Save to workspace:
There was a problem saving the contents of the editor to the workspace. The cursor will be positioned just after the last successful definition.
Check the Commander for possible error message.
I returned to the editor.
The commander error msg was:
AddSlot is a primitive in load.file
[COPYDEF "AddSlot "pprop]
It also said:
Loading startup files ...
Can't find buried subdirectory
Popped to "C:\Program Files\FMSLogo"
shell doesn't like 620 as input
620 is a time delay, which seems necessary.
You seem to have CSS turned off.
Please don't fill out this field.
make "startup [ignore (shell [\"C:\\Program Files\\FMSLogo\\savelog.bat\"] "true) dribble "Harvey.log]
as the first and only line in your Startup.lgo script.
I'm not sure "copy Harvey.hst + Harvey.log Harvey.hst" will work, you can try
copy Harvey.log + Harvey.hst Harvey.tmp
ren Harvey.tmp Harvey.hst
This worked for me... I hope this helps!
BTW, your problem description is quite clean and understandable, i had no problem reproducing and fixing your problem and this was not an easy one... :D
D, or medic, or whoever you are:
Thank you, Thank you, Thank you.
Since I need to keep my full Startup.lgo as it contains code to load all of my dynamic libraries, about 2400 lines of utilities, I've written over the past 20+ years, and is the basis for my Knowledge processing system, I thought I'd go straight for the absolute gold, so...
I simply replaced my line:
SHOW (shell "savelog.bat 620)
with your line:
ignore (shell [\"C:\\Program Files\\FMSLogo\\savelog.bat\"] "true)
I've tested it and it works just fine!!!
FYI - My original copy Harvey.hst + Harvey.log Harvey.hst also works just fine!
ignore works better than SHOW,
also, the documentation clearly states that the 'wait' parameter must be "True or "False.
My error. I had previously needed a wait command to allow for the the execution to take place, so when I saw a parameter labeled 'wait' I assumed, wrongly that it wanted the time to wait.
People don't want Computers...
They want Answers...
Thanks for the quick response, Relja.
Bob, I'm glad you found a way to work-around the problem. I've been pretty careful to maintain backward compatibility with MSWLogo, so I'm surprised that there's something which worked in MSWLogo that doesn't work in FMSLogo. I'd like to understand the root cause, instead of just finding a different way that works.
The only incompatibility that I can think of is that MSWLogo never showed you when it encountered an error in a startup file. So just having SHELL without an IGNORE or a SHOW would cause MSWLogo to silently stop processing further instructions, but it would never give you any indication that this happened. In FMSLogo, you get a clear indication of your bug. Is your SHELL instruction the final instruction in startup.lgo, by any chance? That's the only way I can see your setup working in MSWLogo.
As for the bizarre error message, saving your file and rerunning it caused the COPYDEF command to be run twice. The first time, it gave pprop the name AddSlot. The second time it couldn't, because AddSlot was already defined as a primitive (pprop). To see this more clearly, run this:
COPYDEF "newcopy "pprop
COPYDEF "newcopy "pprop
And you'll get the same bizarre error message.
Thanks for responding.
Yes, your error messages are more useful than MSWLogo's, and I appreciate that. Many systems when they detect an error, simply state: "You did something wrong". Not much help. But it's M$Soft's default attitude.
However, this is something I've fought for for over 4 decades. For software to detect an 'error' it must, ALWAYS, compare a live input to an expected value. If they are different there is an 'error'. Simple humanity says that you tell the user what you were expecting... Sometimes this requires BOTH a format an an example.
For example: I was expecting a <filespec>, ex: [\"C:\\Program Files\\FMSLogo\\savelog.bat\"]
Caution: note double quotes to overcome a space in the directory name, and the necessity for double "\\" so Logo doesn't throw one away...
FMSLogo has made great strides in this direction...
Root cause: I think we found it: my misuse of the shell command.
This was the last big hurdle in moving my code, a substantial amount, creating a Knowledge System from MSWLogo to FSMLogo.
Glad to be on board.
I hope over time I can contribute to your excellent product.
'I am only one; but I am still one.
I cannot do everything, but still I can do something.
I will not refuse to do the something I can do.'
-- Helen Keller