Shop OBEX P1 Docs P2 Docs Learn Events
FlexProp: a complete programming system for P2 (and P1) - Page 6 — Parallax Forums

FlexProp: a complete programming system for P2 (and P1)

13468954

Comments

  • David Betz wrote: »
    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.
    David Betz wrote: »
    yeti wrote: »
    The examples distributed with FlexGUI?

    Is there a separate repository with the examples?

    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").
  • JGM wrote: »
    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
  • David BetzDavid Betz Posts: 14,511
    edited 2019-12-21 16:16
    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?
    make -C loadp2
    mkdir -p ./build
    gcc -Wall -Og -g -DMACOSX -o build/loadp2 loadp2.c loadelf.c osint_linux.c u9fs/u9fs.c u9fs/authnone.c u9fs/print.c u9fs/doprint.c u9fs/rune.c u9fs/fcallconv.c u9fs/dirmodeconv.c u9fs/convM2D.c u9fs/convS2M.c u9fs/convD2M.c u9fs/convM2S.c u9fs/readn.c
    fastspin -2 -o board/P2ES_flashloader.bin board/P2ES_flashloader.spin2
    make[1]: fastspin: No such file or directory
    make[1]: *** [board/P2ES_flashloader.bin] Error 1
    make: *** [loadp2/build/loadp2] Error 2
    
    However, after putting the flexgui/spin2cpp/build directory in my path the make completed successfully.
  • RaymanRayman Posts: 13,767
    edited 2019-12-21 18:34
    I just added GitHub to my Visual Studio setup. I'm hoping this will let me more easily work on projects both at home and at work.
    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...
  • Rayman wrote: »
    I wonder how difficult it is to add Git to an editor like FlexGui… Or, if it's even a good idea...
    If everything everyone wants gets added to FlexGUI, it will be the first serious competitor to Emacs! I vote for adding Orgmode 1st... :-Þ
  • 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?
  • David Betz wrote: »
    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.
  • ersmith wrote: »
    David Betz wrote: »
    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.

  • ersmith wrote: »
    JGM wrote: »
    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. :)
  • I'm kind of conflicted about #include behavior.

    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).
  • JRoark wrote: »
    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.

  • David Betz wrote: »
    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. :)
  • JRoark wrote: »
    David Betz wrote: »
    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.
  • yetiyeti Posts: 818
    edited 2019-12-22 21:09
    Why should including the same text multiple times be forbidden?
    $ cat test.bh
    print rnd(1)
    
    $ cat test.bas
    #include "test.bh"
    #include "test.bh"
    #include "test.bh"
    #include "test.bh"
    
    $ 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
    
    $ spinsim -b test.binary 
    0.9866
    0.5245
    0.6519
    0.6485
    
    It does exactly what I expect.
  • Cluso99Cluso99 Posts: 18,066
    In my OS I include _hwdef.spin in every module as it keeps the EQU's defined in one place. This is good programming. For it to fail is a problem/bug.
  • potatoheadpotatohead Posts: 10,253
    edited 2019-12-23 04:42
    Multiple includes should just be a warning case, IMHO.
  • yetiyeti Posts: 818
    edited 2019-12-23 07:39
    potatohead wrote: »
    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:
    $ cat moo.bh
    #ifndef __moo_bh__
    #define __moo_bh__
    
    print "Moo!"
    
    #endif
    
    $ cat cow.bas
    #include "moo.bh"
    #include "moo.bh"
    #include "moo.bh"
    
    $ 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.

    You already can get warnings if you do it right:
    $ cat moo.bh 
    #ifdef __moo_bh__
    #warning "Bark! Bark!"
    #else
    #define __moo_bh__
    
    print "Moo!"
    
    #endif
    
  • @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.
  • That works for me. Redefining (or double-defining) a function is certainly cause for an error message.
  • Cluso99Cluso99 Posts: 18,066
    @eric,
    That works for me and is as expected too :)
  • potatoheadpotatohead Posts: 10,253
    edited 2019-12-23 16:33

    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.

  • I've created a new release of FlexGUI (or flexgui, or Flexgui, or however you want to capitalize it :) ). The Windows binaries are available at:

    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.

  • @ersmith, your post is to wordy. Just take out 'basically intended to be'

    strike it.

    Mike
  • 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)
    

    FontErrors.png

    dgately
    1648 x 1522 - 851K
  • @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.

    Thanks,
    Eric
  • dgatelydgately Posts: 1,620
    edited 2020-01-06 14:56
    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
  • dgately wrote: »
    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.

    Thanks,
    Eric
  • Feature request from a patron :smile:

    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!
Sign In or Register to comment.