I keep updating and building my spin2cpp and loadp2 clones. Assuming I want to do command line programming is there anything I am missing by not using FlexGUI?
Nothing too significant, I think. The FlexGUI editor is functional but pretty basic, not as nice as something like Rayman's SpinEdit. I've tried to make FlexGUI a convenient package with the fastspin compiler, loadp2, and interfaces to 3 interpreters (TAQOZ in ROM, micropython, and proplisp) but ultimately all the work is done through fastspin and loadp2, so if you have those you're good to go.
No, but you could certainly clone just the flexgui repository and not its submodules. Or, you could clone flexgui + submodules and use that to build spin2cpp and loadp2 (via "make install").
Thanks - I guess I was getting a bit bleary eyed when I posted and didn't manage to see the obvious. I did not build it using "make install". I used the windows install and added the missing components (fastspin, spin2cpp, and loadp2) manually. Adding mac_terminal.sh gets rid of the error message. That said, the loadp2 terminal window pops up but the prop isn't programmed. Using loadp2 manually works however so I am good to go.
The prop isn't programmed? That's odd. What happens when you try to do a "Compile & Run on P2"? Do you get any error messages?
As was indicated elsewhere in the thread, you're not really missing much if you do everything from the command line. Still, the GUI interface should work, so I'd like to figure out what's wrong.
I tried cloning flexgui but I ran into this issue building it. Is this because fastspin wasn't installed prior to trying to build loadp2? It was certainly built. Or do I have to make sure my PATH is set to include the build directory for fastspin? Maybe the Makefile should use an explicit path to fastspin?
Okay, I'm now using the files in flexgui as my command line tools. Now I'm wondering if I'm guaranteed to be using the most recent version of spin2cpp and loadp2 if I use the submodules of flexgui. Do you always update the submodules in flexgui whenever you commit changes to spin2cpp and loadp2?
Okay, I'm now using the files in flexgui as my command line tools. Now I'm wondering if I'm guaranteed to be using the most recent version of spin2cpp and loadp2 if I use the submodules of flexgui. Do you always update the submodules in flexgui whenever you commit changes to spin2cpp and loadp2?
The default for git submodules is to use the particular version checked in to the main repository. To use the latest version you'll have to switch the submodules to their "master" branches:
cd flexgui/spin2cpp
git checkout master
git pull
cd ../loadp2
git checkout master
git pull
The "git checkout master" only has to be done once. After that "git pull" inside the submodules will fetch the top of tree. If you ever do a "git submodule update" then you may have to do the "git checkout master" again.
Okay, I'm now using the files in flexgui as my command line tools. Now I'm wondering if I'm guaranteed to be using the most recent version of spin2cpp and loadp2 if I use the submodules of flexgui. Do you always update the submodules in flexgui whenever you commit changes to spin2cpp and loadp2?
The default for git submodules is to use the particular version checked in to the main repository. To use the latest version you'll have to switch the submodules to their "master" branches:
cd flexgui/spin2cpp
git checkout master
git pull
cd ../loadp2
git checkout master
git pull
The "git checkout master" only has to be done once. After that "git pull" inside the submodules will fetch the top of tree. If you ever do a "git submodule update" then you may have to do the "git checkout master" again.
Thanks for the instructions but that seems like a lot of work. Instead I'm just going to clone all three projects: spin2cpp, loadp2, flexgui and I'll use loadp2 and fastspin out of their own repositories and only use flexgui for the samples.
I'm going to be making a ribbon cable/DIP socket adapter to swap in the P2 eval board for the P1 on an existing project soon, and porting the code to P2, and I'll probably end up using FlexGUI + the associated tools to do that. The work that goes into it is definitely appreciated.
Thanks - I guess I was getting a bit bleary eyed when I posted and didn't manage to see the obvious. I did not build it using "make install". I used the windows install and added the missing components (fastspin, spin2cpp, and loadp2) manually. Adding mac_terminal.sh gets rid of the error message. That said, the loadp2 terminal window pops up but the prop isn't programmed. Using loadp2 manually works however so I am good to go.
The prop isn't programmed? That's odd. What happens when you try to do a "Compile & Run on P2"? Do you get any error messages?
As was indicated elsewhere in the thread, you're not really missing much if you do everything from the command line. Still, the GUI interface should work, so I'd like to figure out what's wrong.
Regards,
Eric
Well this is embarrassing. I just gave it another go and everything works as expected. One possible explanation is that I didn't open loadp2 in the terminal first, which allows me to give it permission to run, before using flexgui. I have noticed that under the latest OS (10.15 Catilina) the OS is more persnickety about running programs.
Sloppy BASIC coders (waves own hand furiously!!) might want to take note of this: FlexGUI 4.0.5 now enforces strict compliance with how you deal with #INCLUDEd files. Each included file can be called once, and only once.
Previous to Version 4.0.5, if you called the same #INCLUDE file multiple times from other #INCLUDEd files, the compiler would accept it silently and soldier on. In 4.0.5, you can only call a file as an #INCLUDEd file *once*. Multiple attempts will throw an "error: redefining function MYFUNCTIONNAME$" followed by a "warning: duplicate definition for MYFUNCTIONNAME$".
Example: Lets say your main program #INCLUDEs a file called "MathFuncs". If "MathFuncs" includes an include reference to "PrettyStrings", this is fine. But if you *also* put a reference to "PrettyStrings" in the main program, the compiler is going to squawk.
This isn't a bug. The compiler seems to be getting smarter and isnt tolerating sloppiness, so adapt accordingly.
Example: So the main program X uses some functions from library Y. Main program X also includes library Z. Internally library Z includes some functions from library Y.
This would fail because library Y was included twice.
Do we have to get into the mess of wrapping #ifndef constant #include file #define constant just to not trip up the compiler? (Like C, ugh).
Sloppy BASIC coders (waves own hand furiously!!) might want to take note of this: FlexGUI 4.0.5 now enforces strict compliance with how you deal with #INCLUDEd files. Each included file can be called once, and only once.
Previous to Version 4.0.5, if you called the same #INCLUDE file multiple times from other #INCLUDEd files, the compiler would accept it silently and soldier on. In 4.0.5, you can only call a file as an #INCLUDEd file *once*. Multiple attempts will throw an "error: redefining function MYFUNCTIONNAME$" followed by a "warning: duplicate definition for MYFUNCTIONNAME$".
Example: Lets say your main program #INCLUDEs a file called "MathFuncs". If "MathFuncs" includes an include reference to "PrettyStrings", this is fine. But if you *also* put a reference to "PrettyStrings" in the main program, the compiler is going to squawk.
This isn't a bug. The compiler seems to be getting smarter and isnt tolerating sloppiness, so adapt accordingly.
Maybe it would be better if FastBASIC just ignored the second include of the same file as if there was a "#pragma once" at the start of it.
Maybe it would be better if FastBASIC just ignored the second include of the same file as if there was a "#pragma once" at the start of it.
That's the behavior that I would prefer (being a true code-slob at heart), but I'm not sure how far Eric needs (or should) go to make the compiler cover our mistakes.
I'm fine with it either way, just as long as it eventually becomes a "standard" for FlexBASIC and a mention of the behavior finds its way into the final docs.
What I'm doing as a work-around now is using a "master" include file... of include files. I put it at the start of the main program, and it (literally) "includes" everthing but the kitchen sink. The compiler doesn't suffer from this apparent bloat. If a sub/function is present in the include, but is never called by anything, it's excluded from the compilation process. Yup, its pretty ham-fisted, but then again... you should see my code.
Maybe it would be better if FastBASIC just ignored the second include of the same file as if there was a "#pragma once" at the start of it.
That's the behavior that I would prefer (being a true code-slob at heart), but I'm not sure how far Eric needs (or should) go to make the compiler cover our mistakes.
I'm fine with it either way, just as long as it eventually becomes a "standard" for FlexBASIC and a mention of the behavior finds its way into the final docs.
What I'm doing as a work-around now is using a "master" include file... of include files. I put it at the start of the main program, and it (literally) "includes" everthing but the kitchen sink. The compiler doesn't suffer from this apparent bloat. If a sub/function is present in the include, but is never called by anything, it's excluded from the compilation process. Yup, its pretty ham-fisted, but then again... you should see my code.
It's not necessarily a mistake. I could write a program that uses both module A and module B and I shouldn't need to be aware of the fact that module A itself also uses module B.
$ fastspin test.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.5 Compiled on: Dec 22 2019
test.bas
random.c
fmt.c
test.pasm
Done.
Program size is 8680 bytes
Multiple includes should just be a warning case, IMHO.
Multiple includes of the same file shall just do what the coder commands: Put the same text literally into the source.
Nothing other is the job of '#include'.
The preprocessor is not a library manager!
You'll find '#ifdef' constructs like this in the C world too:
$ fastspin cow.bas
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.5 Compiled on: Dec 22 2019
cow.bas
fmt.c
cow.pasm
Done.
Program size is 1864 bytes
$ spinsim -b cow.binary
Moo!
Please don't make a preprocessor which behaves in a well known and well understood way everywhere behave different in the surroundings of the Propeller only. That only would harm.
@yeti has said this very well, but I'll say it too just to be clear: "#include" is not at all the same as "OBJ" in Spin. #include just literally puts the contents of the specified file into the source code at that point. That sometimes works well if the file is #included multiple times, and it sometimes does not work well. If you want to make sure a file will only be processed once, the usual way is to wrap it in a #ifndef of a symbol that only it defines:
// this is include file bar.h
#ifndef BAR_H
#define BAR_H
... stuff that is only processed once ...
#endif
In C there is also a special directive "#pragma once" that serves a similar function of making sure the contents of the file are processed only once. This only works in the C preprocessor, the Spin and BASIC preprocessors are different and do not have this (yet).
All of this is totally standard stuff and I have no intention of changing any of it.
The original problem @JRoark ran into is because I intended for fastspin to ignore redefinitions of functions with the same contents; that is, if you said:
SUB foo
print "hello"
END SUB
SUB foo
print "hello"
END SUB
Then I wanted the second definition of "foo" to be accepted and ignored. Unfortunately this was broken; it was accepting any redefinition, even one that was completely different. This was obviously wrong, and it turns out that correctly detecting duplicate definitions that are identical is tricky for various technical reasons. So for now the compiler will print errors for any redefinition, and it will probably stay that way. If I'm eventually able to detect that the definitions are identical then the error will become a warning in that case.
Again, this is only an issue for #include, not for OBJ or the similar constructs in other languages. You can use the same file multiple times in OBJ the same way you always have in Spin.
All of this is totally standard stuff and I have no intention of changing any of it.
Great. The only reason I mentioned a warning was information related. The way things work is great!
I am productive in FastGUI. Love it. And the spartan feature set is a big part of that. Frankly, where there are few options, getting to the right one is fast and easy. I do not care about best or optimal.
I get small bits of P2 time at present. An hour, sometimes a few. With FastGUI, I am in and writing the line of code quick. The hyperlink style error log is my favorite feature. The list file is my second favorite.
Both of these show me what I need to know and do so clearly.
The latest version, 4.0.6, has a number of bug fixes for the fastspin compiler and loadp2 file server.
Just to summarize for those who aren't familiar with it: FlexGUI is a front end for P1 and P2 development that supports Spin, PASM, BASIC, and C programming (compiling all of these languages to P1 or P2 binaries, depending on the user's selection). On P2 it also has simple connections to the version of Forth built in to the P2 ROM (TAQOZ) and to the micropython and proplisp interpreters, which are provided as samples. It's basically intended to be a one stop shop for P2 programming.
I get errors on macOS when trying to make font changes within the Editor Appearance dialog window:
1. Trying to change the Source code text font, this error is returned:
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive
while executing
"tk fontchooser configure -parent . -font "$curfont" -command resetFont"
(procedure "doSelectFont" line 4)
invoked from within
"doSelectFont"
invoked from within
".editopts.font.change invoke "
invoked from within
".editopts.font.change instate {pressed !disabled} { .editopts.font.change state !pressed; .editopts.font.change invoke } "
(command bound to event)
2. Trying to change the Compiler output font, I get thus error:
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive
while executing
"tk fontchooser configure -parent . -font "$config(botfont)" -command resetBottomFont"
(procedure "doSelectBottomFont" line 3)
invoked from within
"doSelectBottomFont"
invoked from within
".editopts.bot.change invoke "
invoked from within
".editopts.bot.change instate {pressed !disabled} { .editopts.bot.change state !pressed; .editopts.bot.change invoke } "
(command bound to event)
@dgately : The font chooser was added in Tcl/Tk 8.6, and it appears you only have version 8.5. I think there should be updated binaries for the Mac available on the web.
If you only knew... Getting Tcl/Tk 8.6 to install and exec on macOS was a mind-boggling experience. It required uninstalling all Homebrew variants of Python, Python3 & Tcl/Tk, then re-installing from Python.org & ActiveTcl, and aliasing all references to Python3, Tcl/Tk 8.6 & Wish 8.6 to the new installations... Now wish works, for this case, but I fear other homebrew-installed executables that require Python will probably be broken now that Python3 is installed 🤢outside of homebrew. A task for another day, I guess!
If you only knew... Getting Tcl/Tk 8.6 to install and exec on macOS was a mind-boggling experience. It required uninstalling all Homebrew variants of Python, Python3 & Tcl/Tk, then re-installing from Python.org & ActiveTcl, and aliasing all references to Python3, Tcl/Tk 8.6 & Wish 8.6 to the new installations...
Ouch, sorry to hear that. I'll see if I can come up with some other solution. Ideally I guess we'd build the wish interpreter ourselves (as we do for Windows) but there's a fair amount of configuration required to make that happen.
At some point could it be put on the roadmap to be able to directly load the program through the P2 eval board, directly to the SD card as a boot file? I think it would necessitate loading a program on the P2 to do that, and then reset the P2 so it can boot from SD. This is a "like to have", but would give a lot of polish!
Comments
Nothing too significant, I think. The FlexGUI editor is functional but pretty basic, not as nice as something like Rayman's SpinEdit. I've tried to make FlexGUI a convenient package with the fastspin compiler, loadp2, and interfaces to 3 interpreters (TAQOZ in ROM, micropython, and proplisp) but ultimately all the work is done through fastspin and loadp2, so if you have those you're good to go.
No, but you could certainly clone just the flexgui repository and not its submodules. Or, you could clone flexgui + submodules and use that to build spin2cpp and loadp2 (via "make install").
The prop isn't programmed? That's odd. What happens when you try to do a "Compile & Run on P2"? Do you get any error messages?
As was indicated elsewhere in the thread, you're not really missing much if you do everything from the command line. Still, the GUI interface should work, so I'd like to figure out what's wrong.
Regards,
Eric
Got me thinking...
I wonder how difficult it is to add Git to an editor like FlexGui… Or, if it's even a good idea...
The default for git submodules is to use the particular version checked in to the main repository. To use the latest version you'll have to switch the submodules to their "master" branches: The "git checkout master" only has to be done once. After that "git pull" inside the submodules will fetch the top of tree. If you ever do a "git submodule update" then you may have to do the "git checkout master" again.
Well this is embarrassing. I just gave it another go and everything works as expected. One possible explanation is that I didn't open loadp2 in the terminal first, which allows me to give it permission to run, before using flexgui. I have noticed that under the latest OS (10.15 Catilina) the OS is more persnickety about running programs.
Previous to Version 4.0.5, if you called the same #INCLUDE file multiple times from other #INCLUDEd files, the compiler would accept it silently and soldier on. In 4.0.5, you can only call a file as an #INCLUDEd file *once*. Multiple attempts will throw an "error: redefining function MYFUNCTIONNAME$" followed by a "warning: duplicate definition for MYFUNCTIONNAME$".
Example: Lets say your main program #INCLUDEs a file called "MathFuncs". If "MathFuncs" includes an include reference to "PrettyStrings", this is fine. But if you *also* put a reference to "PrettyStrings" in the main program, the compiler is going to squawk.
This isn't a bug. The compiler seems to be getting smarter and isnt tolerating sloppiness, so adapt accordingly.
Example: So the main program X uses some functions from library Y. Main program X also includes library Z. Internally library Z includes some functions from library Y.
This would fail because library Y was included twice.
Do we have to get into the mess of wrapping #ifndef constant #include file #define constant just to not trip up the compiler? (Like C, ugh).
That's the behavior that I would prefer (being a true code-slob at heart), but I'm not sure how far Eric needs (or should) go to make the compiler cover our mistakes.
I'm fine with it either way, just as long as it eventually becomes a "standard" for FlexBASIC and a mention of the behavior finds its way into the final docs.
What I'm doing as a work-around now is using a "master" include file... of include files. I put it at the start of the main program, and it (literally) "includes" everthing but the kitchen sink. The compiler doesn't suffer from this apparent bloat. If a sub/function is present in the include, but is never called by anything, it's excluded from the compilation process. Yup, its pretty ham-fisted, but then again... you should see my code.
Nothing other is the job of '#include'.
The preprocessor is not a library manager!
You'll find '#ifdef' constructs like this in the C world too: Please don't make a preprocessor which behaves in a well known and well understood way everywhere behave different in the surroundings of the Propeller only. That only would harm.
You already can get warnings if you do it right:
All of this is totally standard stuff and I have no intention of changing any of it.
The original problem @JRoark ran into is because I intended for fastspin to ignore redefinitions of functions with the same contents; that is, if you said: Then I wanted the second definition of "foo" to be accepted and ignored. Unfortunately this was broken; it was accepting any redefinition, even one that was completely different. This was obviously wrong, and it turns out that correctly detecting duplicate definitions that are identical is tricky for various technical reasons. So for now the compiler will print errors for any redefinition, and it will probably stay that way. If I'm eventually able to detect that the definitions are identical then the error will become a warning in that case.
Again, this is only an issue for #include, not for OBJ or the similar constructs in other languages. You can use the same file multiple times in OBJ the same way you always have in Spin.
That works for me and is as expected too
Great. The only reason I mentioned a warning was information related. The way things work is great!
I am productive in FastGUI. Love it. And the spartan feature set is a big part of that. Frankly, where there are few options, getting to the right one is fast and easy. I do not care about best or optimal.
I get small bits of P2 time at present. An hour, sometimes a few. With FastGUI, I am in and writing the line of code quick. The hyperlink style error log is my favorite feature. The list file is my second favorite.
Both of these show me what I need to know and do so clearly.
https://github.com/totalspectrum/flexgui/releases
The latest version, 4.0.6, has a number of bug fixes for the fastspin compiler and loadp2 file server.
Just to summarize for those who aren't familiar with it: FlexGUI is a front end for P1 and P2 development that supports Spin, PASM, BASIC, and C programming (compiling all of these languages to P1 or P2 binaries, depending on the user's selection). On P2 it also has simple connections to the version of Forth built in to the P2 ROM (TAQOZ) and to the micropython and proplisp interpreters, which are provided as samples. It's basically intended to be a one stop shop for P2 programming.
strike it.
Mike
1. Trying to change the Source code text font, this error is returned:
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive while executing "tk fontchooser configure -parent . -font "$curfont" -command resetFont" (procedure "doSelectFont" line 4) invoked from within "doSelectFont" invoked from within ".editopts.font.change invoke " invoked from within ".editopts.font.change instate {pressed !disabled} { .editopts.font.change state !pressed; .editopts.font.change invoke } " (command bound to event)2. Trying to change the Compiler output font, I get thus error:
bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive bad option "fontchooser": must be appname, caret, scaling, useinputmethods, windowingsystem, or inactive while executing "tk fontchooser configure -parent . -font "$config(botfont)" -command resetBottomFont" (procedure "doSelectBottomFont" line 3) invoked from within "doSelectBottomFont" invoked from within ".editopts.bot.change invoke " invoked from within ".editopts.bot.change instate {pressed !disabled} { .editopts.bot.change state !pressed; .editopts.bot.change invoke } " (command bound to event)dgately
Thanks,
Eric
If you only knew... Getting Tcl/Tk 8.6 to install and exec on macOS was a mind-boggling experience. It required uninstalling all Homebrew variants of Python, Python3 & Tcl/Tk, then re-installing from Python.org & ActiveTcl, and aliasing all references to Python3, Tcl/Tk 8.6 & Wish 8.6 to the new installations... Now wish works, for this case, but I fear other homebrew-installed executables that require Python will probably be broken now that Python3 is installed 🤢outside of homebrew. A task for another day, I guess!
see: https://opensource.com/article/19/5/python-3-default-mac
see: https://discourse.brew.sh/t/cannot-get-python-to-use-tcl-tk-version-8-6/3563
dgately
Ouch, sorry to hear that. I'll see if I can come up with some other solution. Ideally I guess we'd build the wish interpreter ourselves (as we do for Windows) but there's a fair amount of configuration required to make that happen.
Thanks,
Eric
At some point could it be put on the roadmap to be able to directly load the program through the P2 eval board, directly to the SD card as a boot file? I think it would necessitate loading a program on the P2 to do that, and then reset the P2 so it can boot from SD. This is a "like to have", but would give a lot of polish!