FMSLogo Activity
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Activity for FMSLogo
-
David Costanzo modified ticket #605
apply [[] [] abc ] [] crashes FMSLogo
-
I simplified the repro case to APPLY [[] [] abc ] [] When I wrote the APPLY instruction in the first description, I was trying to get a syntax error in the second line to force a cleanup (untreeify) of the entire body. However, I messed up because the second instruction isn't a list, it's the word "(LIST. The problem isn't that the second instruction can't be parsed, it's that the instructions are assumed to be lists. Therefore, I think the correct behavior is to throw an error like APPLY doesn't...
-
APPLY [[] [IGNORE 1](LIST "\}) ] [] crashes FMSLogo
-
Update logic that checks if FMSLogo is running on startup to use wxSingleInstanceChecker on Windows.
-
[r6141] fixes NAME using a similar strategy that I used for QUEUE and DEQUEUE. This will also be available in FMSLogo 8.5.0.
-
Vilim writes: If quoted was a primitive, it could just call maybe_quote... If backtick was a primitive, making performant macros would be so much easier... Both those statements are true. Similarly, I could have fixed this bug by making QUEUE and DEQUEUE primitives instead of macros. However, I try to avoid adding new primitives due to the compatibility risk. Any existing program which defines a procedure with the same name as the new primitive won't run on the new FMSLogo. This is a small risk,...
-
Apply the fix for Bug #598 to NAME.
-
Vilim asks Is [first [x]] the most efficient way to construct a value that evaluates to x when fed into run regardless of the type of x? Better than using quoted? By my measurements, yes, it's faster. The outer list is necessary, so the difference is really between (FIRST (LIST :x)) and (QUOTED :x). Since FIRST and LIST are primitives, they're faster. Here's an updated PerfTest that's more sensitive to DEQUEUE's performance. It uses non-words in the queue so that QUOTED does less computation. To...
-
Remove what may be redundant logic in begin_apply.
-
DanielAjoy posted a comment on ticket #600
Thanks David, Very much appreciate the time you've spent tracking this bug down. I'm going to start using the attached pre-release version. It loaded LogoFE normally (no issues there) and I ran a few commands that I thought might have some interplay with nested APPLYs, and so far so good. I'll keep you posted if something related to this issue comes up again.
-
Refactoring: Replace a for loop with no initialization statement with a while loop.
-
Refactoring: Move a local variable declaration and assignment closer to where the variable is first used.
-
Inner procedure call modifying variable in outer scope
-
I have committed a fix with [r6136]. Although the fix was relatively simple, it does not follow the code in UCBLogo, which makes less confident in it. The updated code passes all my tests, but that doesn't mean that my fix didn't introduce new problems. I have attached a pre-release version of the update, in case you'd like to test it before it's release in FMSLogo 8.5.0.
-
Update test log with output from new tests.
-
Vilim posted a comment on ticket #598
If quoted was a primitive, it could just call maybe_quote... If backtick was a primitive, making performant macros would be so much easier...
-
Fix Bug #600; A procedure which runs a tail-called APPLY no longer leaks its parameters into the caller's scope.
-
Add a bad input test to APPLY that crashes UCBLogo but not FMSLogo.
-
APPLY [[[x]] :x] [1] crashes FMSLogo
-
Vilim asks Is [first [x]] the most efficient way to construct a value that evaluates to x when fed into run regardless of the type of x? Better than using quoted? By my measurements, yes, it's faster. The outer list is necessary, so the difference is really between (FIRST (LIST :x)) and (QUOTED :x). Since FIRST and LIST are primitives, they're faster. Here's an updated PerfTest that's more sensitive to DEQUEUE's performance. It uses non-words in the queue so that QUOTED does less computation. To...
-
Rewrite some tests which log very long lines to instead log short lines.
-
Use wxSingleInstanceChecker to detect if another instance of FMSLogo is running on startup.
-
Refactoring: Rename NODETYPES to NODETYPE.
-
Change NODETYPES from "unsigned short" to an enum.
-
I spotted an interesting idiom in the new dequeue implementation! Is [first [x]] the most efficient way to construct a value that evaluates to x when fed into run regardless of the type of x? Better than using quoted?
-
I have updated QUEUE and DEQUEUE to use the same parameter names used in UCBLogo in [r6112]. This does not fix the bug, but it mitigates the bug by making a conflict less likely. It also makes it so that a logo program that works in UCBLogo won't fail in FMSLogo and vice-versa. Even less likely parameter names could have been chosen, such as ones that include a space in their name, but I think there's value in have the same bug as UCBLogo until the bug is fixed. I had hoped to fix this completely,...
-
QUEUE and DEQUEUE don't work with some variable names
-
I fixed the macro bug, which enabled me to use Vilim's suggestion of converting QUEUE and DEQUEUE into macros to avoid the naming conflict. This is implemented in [r6130]. It will be available in FMSLogo 8.5.0. When I used pure macros as Vilim provided, the procedures became much slower. I worked out a hybrid solution, similar in spirit to what the .MACRO documentation recommends. The general macros are only used when there's a naming conflict. Otherwise, the code looks a lot like it did before....
-
Fix Bug #598; QUEUE and DEQUEUE now behave correctly when the queue name is shadowed by one of their own local variables.
-
Update the tests so that a full test pass can run on GNU/Linux.
-
STOP before an unknown procedure still throws "don't know how to" error
-
Refactoring: Replace CURRENTWORKINGDIRECTORY with GETCURRENTDIRECTORY in dllcall.
-
Adjust some of the assert statements that I had added to the inline functions.
-
Fix a typo in a comment
-
I simplified the example as much as I could: to a (show b 1 :variable) end to b :variable output apply [[x] 2] [3] end a 2 1 a should throw an error because :variable is not defined. Instead, it prints 2 1. The 2 is correct, as that's what b 1 outputs. If the named-slot template in the apply is changed to a named procedure template or an explicit slot template, then problem does not reproduce.
-
Comment out the "assert(is_tree(tree))" that I recently added to settreepair__tree(tree, treepair).
-
Add comments to explain the purpose and function of the two different stacks used by the evaluator.
-
Fix an inaccurate claim in a comment.
-
Rewrite directory_helper in terms wxWidgets instead of in terms of WIN32 API.
-
Replace "TRUE" with "true" because ther literal is used as a bool, not a BOOLEAN.
-
Change some #define constants into "const" values.
-
Refactoring: Change #define macros into inline functions.
-
Refactoring: Move the logic for pushing the macro_return continuation until after it's been confirmed that proc is defined.
-
Remove misinformation from the comment for the eval_sequence_continue label.
-
Remove inaccurate comments from the apply_dispatch label.
-
Fix an incorrect claim in a comment.
-
I had previously written: It might even be a duplicate of Bug #599. I fixed bug #599 and this bug (Bug #600) remains, so this is not duplicate.
-
macro evaluated in context of macro body not caller when output is used
-
I have committed a fix for this as [r6114]. The fix will be available in whatever version follows 8.4.0. The fix doesn't follow the UCBLogo code.
-
Fix Bug #599; The output list of macros that are run as input to a procedure and which define local variables are now evaluated in the caller's context, not the context of the macro.
-
Here's a slightly simpler macro that shows the problem: .MACRO MACRO_THING :name OUTPUT [:name] END
-
Manfred Zindel posted a comment on ticket #68
I've been thinking about my FORWARD-0 trick. When I first saw it, I wondered: Is this an undocumented extra feature I can use before someone notices the error? Then I thought about it some more and realized: It's not an error at all; it's a regular part of the language. If you remove it, THEN you're making a mistake. Now, to get straight to the point: I think FORWARD 0 belongs to FMSLogo, and so does the circular shape. FORWARD allows any positive and (!) negative number that can be represented on...
-
Well, your variation did its job at once: SETPOS with a list was an idea of my chatbot OPERA AI. You're right - I could take BITBLOCK to restrict an animation to only a part of the graphics area in order to get a rectangle instead of a circle, I bet it's really pretty fast for a small part. The wish behind it is always to have a very short interruption while going from step to step and so compensate the lack of a background buffer. I never noticed that FILL has a parameter that allows it to use the...
-
That is clever to use a large pen size to erase. It's not documented that the pen is round or that FORWARD 0 draws anything, but given my hesitance to break compatibility with existing programs, I think it's safe to assume I wouldn't change it. When I run your program on my laptop, I don't see any flicker. If I were trying to be clever, I would have used (FILL "TRUE) to fill the shape. To do this, you can choose a color that is slightly off from your PENCOLOR. For example [254 0 0] looks red, but...
-
Reporting a trick for animation - how clever is it?
-
Add regression tests for NAME, including a regression test for Bug #598.
-
I have updated QUEUE and DEQUEUE to use the same parameter names used in UCBLogo in [r6112]. This does not fix the bug, but it mitigates the bug by making a conflict less likely. It also makes it so that a logo program that works in UCBLogo won't fail in FMSLogo and vice-versa. Even less likely parameter names could have been chosen, such as ones that include a space in their name, but I think there's value in have the same bug as UCBLogo until the bug is fixed. I had hoped to fix this completely,...
-
Mitigate Bug #598.
-
I opened Feature Request #143 to track the addition of the screen's scale to MACHINE's output list. It will be included in FMSLogo 8.5.0.
-
Provide a programmatic way to get the current zoom level
-
This is implemented in [r6110]. It will be available in FMSLogo 8.5.0.
-
Standardize on "scale of the screen window" instead of "zoom factor".
-
Implement Feature Request #143; MACHINE now outputs the current screen window scale as the 18th item in the list.
-
Provide a programmatic way to get the current zoom level
-
Fix a broken header guard (thanks gcc for pointing it out!)
-
Add a "See Also" to KEYBOARD to link it to SETFOCUS and GETFOCUS.
-
There are many ways to answer that questions. First is that FMSLogo is GPL, so anyone can pick up the program, extend it, and redistribute it without my permission. That's how I picked up MSWLogo when George Mills's life circumstances made it so that he couldn't work on it anymore. However, no one who has shown interest in doing the same for FMSLogo, now that my life circumstances make it so that I can't work on it anymore. Several people have compiled their own FMSLogo, and one even spent three...
-
Our FMSLogo Developments for Education and Hobbyists
-
I'm glad you were able to solve this. I don't know why you'd think that the Commander has the caption "FMSLogo". When it's docked, it doesn't have a caption. When TEXTSCREEN or FULLSCREEN is used, the caption is "Commander". The window that has the caption "FMSLogo" is either the overall window or the window that holds the drawing surface. This is somewhat irrelevant because "FMSLogo" is a special case that always gives focus to the screen. This is hard-coded into graphwin.cpp: NODE *lsetfocus(NODE...
-
Well, here is finally the solution to the riddle:: (KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] []) SETFOCUS [FMSLogo] Now it works! But what the documentation says is that the screen should have the focus, but isn't it given to the commander by SETFOCUS [FMSLoco}? ~~~ The "Screen" must have focus (NOT the commander) You can force this by calling SETFOCUS [FMSLogo] after you call KEYBOARDON ~~~ Who is who and what is what? Does the caption FMSLogo mean the screen or the commander,...
-
I'd like to make the proposal to add a link to KEYBOARDON at SETFOCUS and GETFOCUS - or to explain a little more about FOCUS at SETFOCUS and GETFOCUS.
-
Now I found some answers in the description of KEYBOARDON itself: Note the "Screen" must have focus (NOT the commander) to catch the key events. You can force this by calling SETFOCUS [FMSLogo] after you call KEYBOARDON. All the "callbacks" for the keyboard are automatically run in NOYIELD mode. But if the Screen needs the focus, why will I have to write SETFOCUS [FMSLogo] after KEYBOARDON and not SETFOCUS [screen]? I think, Copter works in Little Helper because there was the right focus by lucky...
-
To solve the KEYBOARDON-Problem, I need to know everything about Focus in FMSLogo. the documentation of SETFOCUS and GETFOCUS is not very clear, so I cannot be sure what to answer to the following questions: 1. Is FMSLogo the caption (title) of the graphics area or of the commander? And how is the other one, the contrary, called? 2. Are there still more possible captions. and which is the complete set? 3. Which are the consequences of setting the FOCUS to a special caption? 4. How can I find out,...
-
Good news! We went back to our former copter project where a model copter is flying over air photos of our region controlled by arrow keys. We then implemented this unfinished project into a Little Helper environment before we put it into an archive and now managed to transfer it to the actual Little Helper successor four years later, where the development can be continued as soon as we have time for it. So, now we can figure out why the copter works with KEYBOARDON other than our new procedures....
-
Sorry, I forgot what I really copied. It was: (KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] [])
-
Thank you for the examples. Nevertheless, frustration goes on. I copied exactly the following to the commandline on two different machines (notebook and desktop) WINDOWS 11, FMSLogo 8.3.2 and 8.4.0 original. Well, the input was echoed, but when I pressed ESCAPE, there was no reaction whatsoever. The focus was FMSLogo. I tried the same with ENTER and arrow keys, but the answer was nothing at all. Regarding all the complicated things I did in the last days with mouse and TIMER, where FMSLogo followed...
-
I just tested FMSLogo 8.4.0 and KEYBOARDON was able to react to the Escape key on my machine. The easiest way to see KEYBOARDON work is to have it print KEYBOARDVALUE in its callbacks: (KEYBOARDON [SHOW SENTENCE KEYBOARDVALUE "down] [SHOW SENTENCE KEYBOARDVALUE "up]) Here's a simple program that prints when Escape is pressed: (KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] []) Since you mentioned that the things you were doing were complex, it might be worth starting with just...
-
Keyboardon doesn't react
-
Thank you, David, for your answer. You made it clear that widgets on the graphcs screen are not compatible with ZOOM. This is regretable, but no disaster. I can still use a window as parent of the widgets, even if that is not so smart and comfortable as using them directly on the graphics screen. But it's good enough. When using a window, I'll have to rely on dialog units, but you already gave us a procedure to handle them, which worked perfectly already over years. Concerning the possibility to...
-
Thanks for the corrections, Daniel. I committed them as [r6107].
-
Fix some Spanish grammar in the "Pause Mode" dialog.
-
It's true that the dialog widgets that are placed on the drawing surface are incompatible with ZOOM. The feature request you made, to have the current ZOOM level be available by MACHINE makes sense to me. If ZOOM had followed Logo conventions, it would have been named SETZOOM with ZOOM outputting the current zoom level. It's too late to correct that now. Your idea of adding it to what MACHINE outputs has minimal risk to breaking backward compatibility, so it's something I'd be willing to implement....
-
Thanks David, Sure: El programa que se ejecuta actualmente está pausado. Cuando FMSLogo está pausado puedes ejecutar cualquier instrucción que quieras, incluidas las instrucciones para inspeccionar los valores de las variables locales, reanudar la ejecución, o detener el programa por completo. Ejecutar Reanudar la ejecución justo después de la instrucción PAUSA Sigue
-
PAUSE should have self-documenting GUI
-
I have finished implementing the dialog box, as describe. This is committed in [r6106]. This will be first available in FMSLogo 8.5.0, which has no planned release date. I translated it to Spanish but not any other languages. Daniel, you might take a look at the attached screenshot of the Spanish translation, since I'm not a native speaker and don't know the natural way to say that execution is paused.
-
Implement Feature Request #136; the PAUSE dialog now explains what pause mode is and what you can do in it.
-
Regretably there are more problems when using ZOOM. We created a BUTTON with the FMSLogo screen as parent. And it worked womderful when ZOOM was 1. But as soon as ZOOM got another value, say 2 or 0.5, the BUTTON went crazy. First I thought, that it was gone, but it only jumped away in an unpredictable way. It did not simply scale like the ZOOM nor did oit keep its original size. Well, so I thought, it would be bettwer to create an own window for this button. This is not really smart, and it has another...
-
I see. I've got still another question concerning ZOOM. As ZOOM can be used both, interactively and programmatically, the program cannot know whether during the run an interactive ZOOM has been performed. So it would be better, if the program could ask internally for the current size of ZOOM. When items 16 and 17 were added to MACHINE, it allowed us to see from our procedure where the scroll position has gone, and we used this often since then. So I ask, whether there is a possibility to find out...
-
I'm not sure what you're asking, but swapping the order of running BITLOAD and ZOOM shouldn't change the outcome. BITLOAD copies the image to the drawing surface at the exact size of the image. ZOOM changes how much of the drawing surface you see, but it doesn't change what's on the drawing surface. If you BITLOAD while zoomed out or zoomed in and then you run "ZOOM 1" to get back to the 1:1 size, it'll be as if you never had zoomed. You'll see this behavior for all drawing commands, not just BITLOAD....
-
Smart image handling in FMSLogo - responsive design.
-
The text processing inherited from MSWLogo doesn't lend itself well to cool text games. The main problem is that the input is done with modal dialog box, so a text conversation is more awkward than it is in UCBLogo. Another problem is that TYPE doesn't type anything until it gets a newline. In short, I think there's more than just SETTEXTCOLOR that stands in thew way of cool text games. It's good to hear that you're a programmer. Feel free to submit a patch. Please include documentation and tests....
-
Robin Munn posted a comment on ticket #141
Exactly; I felt like I was facing a chicken-and-egg scenario where I couldn't access the %TEMP% variable in order to safely write a temporary file; if I could write a temporary file, then I could access environment vars via outputing to %TEMP%/logo-output-TIMESTAMP.txt. With your hints on using DLLCALL to access the Windows API, I can get an egg to hatch a chicken with, to then get more eggs. Thanks.
-
Didn't know that double-clicking a .lgo file would start FMSLogo in that file's directory; thanks! That would solve my use case, but I think I'll still go with the option of telling parents "Here's the zip file, unzip it in this directory" because that will allow me to preload the zip file I distribute with a startup.logoscript file that automatically records a transcript, plus I can add a few functions (like GETWORKINGDIRECTORY) to the logolib directory in the .zip file I distribute. (I wouldn't...
-
This sounds like a reasonable request. In the meantime, I think you can implement it yourself. You can prefix your shell command with cmd /c and then redirect stdout and stderr to files, read the files into variables, delete the temp files, construct the list, and output it. If you get this working, please post it here. As a proof-of-concept, this following created a file named tmp-output.txt in my user directory. show shell [ cmd /c dir /w > c:/users/david/tmp-output.txt ] You may have to worry...
-
Thanks for the request, Robin. This looks a subset of Feature Request #13. The reason I don't new primitives lightly is that any new primitive risks breaking existing logo programs that happen to have a user-defined procedure of the same name. Changing an existing procedure from printing something to outputting something is even more of a risk, because older programs would get a "you don't say what to do with" error. The most straight-forward way to get the current working directory or an environment...
-
Actually, my use case is probably better served by downloading the FMSLogo .zip file and having students run FMSLogo from the zip. Then they'll automatically have write access, I can customize the .zip file ahead of time to contain a startup.logoscript that runs DRIBBLE so I automatically can see a transcript of each student's activity, and so on. But I still think a PWD function is needed, so I'll leave this ticket open.
-
SETTEXTCOLOR procedure similar to what UCBLogo has
-
I also would like a GETENV procedure (function, really), but if SHELL would output the stdout of what it ran then the absence of GETENV could be worked around with MAKE "CWD SHELL [ CMD /C "ECHO %CD" ], since the CD environment variable is guaranteed to contain the current working directory. This would also be a viable workaround for my request from #140.
-
SHELL should output the stdout and/or stderr of the process it launched
-
Add PWD or similar function to get working directory
1 >