@ManAtWork said:
One of my favorite text editors solves this problem by looking at the file date whenever the window gets focus (again). If the date is newer than when it was originally opened the editor warns you that the file has been changed externally and asks if you want to re-load it. Some editors keep a write lock on open files so you can only open it a second time in read-only mode. That's the safest way but it can also be anoying because you can't rename or move the file to create a backup while it's open.
FlexProp has an "Auto Reload Files if changed externally" option that does this; it's found under Options > Editor Options...
@pik33 you could try turning that option on, it may help with your problems. I can't remember why it's not on by default, but perhaps it should be.
Hello Eric,
it's been a long time since I last worked with FlexProp, must be 2 years or something. I've updated to version 5.9.9 today and got strange error messages since.
"C:/Program Files (x86)/Parallax Inc/flexprop/bin/flexspin" -2 -l --tabs=2 -D_BAUD=230400 -O1 --charset=utf8 -I "C:/Program Files (x86)/Parallax Inc/FlexProp/include" "G:/Projekte/BeamiconII/Source/BeamiModular/P2/B2M_main.c"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.9 Compiled on: Feb 27 2022
B2M_main.c
C:/Program Files (x86)/Parallax Inc/flexprop/include/propeller2.h:10: error: Internal error, expected identifier
C:/Program Files (x86)/Parallax Inc/flexprop/include/propeller2.h:11: error: Internal error, expected identifier
(... and lots more of this)
I can find nothing wrong when I look at lines 10 and up in propeller2.h
#ifndef __PROPELLER2__H
#define __PROPELLER2__H
#include <stdint.h>
#ifndef __FLEXC__
/*
* special cog register names (the actual types are compiler dependent)
* Not all compilers will necessarily support these
*/ // this is line #10
extern volatile uint32_t _IJMP3;
extern volatile uint32_t _IRET3;
I also noticed that p2_clock.h does not support _XTALFREQ == 25000000. This would be nice because the KISS boards use a 25MHz crystal which is also quite common in designs with Ethernet chips like the LAN8720, W5500, W6100 or ENC28J60.
Hmm, this is really strange. I've modified the p2_clock.h file like shown above but I still get a message "C:/Program Files (x86)/Parallax Inc/flexprop/include/sys/p2_clock.h:29: error: #error unknown _XTALFREQ" although the #error line in my file is line #34. It seems like FlexC has those header files stored internally and ignores my modified files. This would also explain the strange error from post #963.
To avoid any confusion with files from older versions I deleted the old folder and re-installed in an empty folder. But that doesn't help. I'm using Windows 7.
@ManAtWork said:
Hello Eric,
it's been a long time since I last worked with FlexProp, must be 2 years or something. I've updated to version 5.9.9 today and got strange error messages since.
"C:/Program Files (x86)/Parallax Inc/flexprop/bin/flexspin" -2 -l --tabs=2 -D_BAUD=230400 -O1 --charset=utf8 -I "C:/Program Files (x86)/Parallax Inc/FlexProp/include" "G:/Projekte/BeamiconII/Source/BeamiModular/P2/B2M_main.c"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.9 Compiled on: Feb 27 2022
B2M_main.c
C:/Program Files (x86)/Parallax Inc/flexprop/include/propeller2.h:10: error: Internal error, expected identifier
C:/Program Files (x86)/Parallax Inc/flexprop/include/propeller2.h:11: error: Internal error, expected identifier
(... and lots more of this)
I can find nothing wrong when I look at lines 10 and up in propeller2.h
Most likely it's some problem in the code immediately before #include <propeller2.h>, because the header file on its own works, e.g. the following program compiles and runs correctly:
@ersmith said:
Are you able to share more of your code for us to look at?
It must have something to do with FlexProp not liking being installed in C:\Program files(x86) and the very strange way windows handles access rights. I already had problems with this issue before on a Windows10 PC but not on Windows7. Last time there were files I created by unzipping the flexprop archive that were visible in the windows explorer but unaccessible by FlexProp. This time it seems to be even more strange, There are digfferent versions of the files and the editor sees different contents than the compiler.
I was able to fix that by installing FlexProp on a completely different partition (not C:). I planned to install VSC anyway and use that as IDE front end for FlexProp. The VSC editor is much more user friendly than the TCL editor. Anyway, it was not the source code that was causing the error messages. It now compiles without problems.
You are correct that program files(x86) is a special location, and only setup.exe type installers should be loading programs and executable files in there.
Program Files (x86) is a symlink for certain permission levels. You are correct that an executable running at a different permission level is going to see this area structured differently.
I usually unzip FlexProp to a C:\P2\flexprop\ folder. Kept it short because I don't like to type long paths. It is not necessary to use a different partition, just keep it out of special folders (appdata, temp, windows, system32, etc). When launching FlexProp for the first time on a common Windows 10 configuration, yes you'll get a SmartScreen popup. Yes you click on Run Anyway, and then it sets up the folder access permissions.
Yea, there's a weird layering thing going on with Program Files. If an unelevated process writes to a file there, it actually ends up in %LOCALAPPDATA%\VirtualStore\Program Files (same for the x86 directory and some other system directories)
Something else must have changed in your environment, because that snippet compiles for me (once I embed it into a function with appropriate local variables). Can you share a more complete piece of your code?
@ersmith
I was moving some code from the Prop tool to Flexprop. Noticed that the || operators and | and ABS are different.
Got error with || flexprop mistook it for ABS. It was a bit confusing until I figured it out.
@pilot : could you show me the code that gave the error? Normally in Spin2 mode FlexProp does understand that || is a logical OR, and I've just checked with some simple examples and they do seem to work.
While trying to search, I often get this instead of the search panel. After closing this error message, the search panel appears but doesn't work.
bad option "tag": must be activate, add, cget, clone, configure, delete, entrycget, entryconfigure, index, insert, invoke, post, postcascade, type, unpost, xposition, or yposition
bad option "tag": must be activate, add, cget, clone, configure, delete, entrycget, entryconfigure, index, insert, invoke, post, postcascade, type, unpost, xposition, or yposition
while executing
"$t tag config hilite -background yellow"
invoked from within
"if ![winfo exists $w] {
toplevel $w
wm title $w "Search"
grid [label $w.1 -text Find:] [entry $w.f -textvar Find] [ttk::button $..."
(procedure "searchrep" line 5)
invoked from within
"searchrep [focus] 0"
invoked from within
".#mbar.#mbar#edit invoke active"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke active]"
(procedure "tk::MenuInvoke" line 50)
invoked from within
"tk::MenuInvoke .#mbar.#mbar#edit 1"
(command bound to event)
Another glitch: ctrl-z (undo) if pressed one time too many, clears the file in the editor window. Then ctrl-y, which should be redo, doesn't work. If there is something in the clipboard, the ctrl-y often inserts the clipboard instead of redo. Xubuntu 20.04.
@pik33 : Thanks for the bug reports. search/replace was bound to too many windows and could get triggered even when the text window did not have focus, which confused things. I've also checked in some fixes for undo/redo. The github repository has those fixes now, I hope to make a binary release "soon".
@iseries said:
Is there a way to allocate memory without loading or increasing the size of the program.
For example: uint32_t data[25000];
This will increase the program size by 100k
uint32_t *data;
data = malloc(100000);
This does not work unless the heapsize is increased to account for the allocation size which increases the program size.
I want my cake and eat it too.
Mike
Global allocations must be included in the program, for the C standard demands them to be filled with zeroes. Heap being pre-allocated is a bit of a quirk, yes.
The only way to allocate memory that's truly uninitialized is from the stack (local variables and alloca)
@ersmith said:
I've uploaded a binary version of FlexProp 5.9.10 to my Patreon page (link in my signature). A public release will follow in a few days.
Bless ya! I was really hoping that life would conspire to give you a chance to release a new version.
I recompiled a new flexprop several minutes ago: it contains old, "slow" sdmm.cc (which I had to replace immediately as the player "depends on" the new one)
@pik33 said:
I recompiled a new flexprop several minutes ago: it contains old, "slow" sdmm.cc (which I had to replace immediately as the player "depends on" the new one)
@pik33 said:
I recompiled a new flexprop several minutes ago: it contains old, "slow" sdmm.cc (which I had to replace immediately as the player "depends on" the new one)
I browsed to it using github's web interface and it has the changes (as I expected):
It seems something went wrong on the machine at the university. Now I repeated the process at home and sdmm.cc seems to be the new one.
There was a mess in the Flexprop directories at the university computer. I simply deleted them (source and installed) and cloned the repository again. Now all seems to be OK: the player compiles and works. This player seems to be one of bigger projects written in FlexBasic
The binaries for flexprop 5.9.10 are up on github. Unfortunately, it seems that Google Chrome on Windows is flagging the file as suspicious because it is "not commonly downloaded". The executable is signed and does not have any viruses, according to all the virus scanners I've tried (and since I built it myself on a Linux machine I think it's virtually impossible for it to be infected by a Windows virus!) so I don't know why Chrome is worried about it. The problem may clear up on its own once enough people have downloaded it. In the meantime, you'll have to manually click on a small arrow to change the "Discard" button to "Keep".
Comments
FlexProp has an "Auto Reload Files if changed externally" option that does this; it's found under Options > Editor Options...
@pik33 you could try turning that option on, it may help with your problems. I can't remember why it's not on by default, but perhaps it should be.
Hello Eric,
it's been a long time since I last worked with FlexProp, must be 2 years or something. I've updated to version 5.9.9 today and got strange error messages since.
I can find nothing wrong when I look at lines 10 and up in propeller2.h
I also noticed that p2_clock.h does not support _XTALFREQ == 25000000. This would be nice because the KISS boards use a 25MHz crystal which is also quite common in designs with Ethernet chips like the LAN8720, W5500, W6100 or ENC28J60.
I think adding
would do the job but I can't test it at the moment.
Hmm, this is really strange. I've modified the p2_clock.h file like shown above but I still get a message "C:/Program Files (x86)/Parallax Inc/flexprop/include/sys/p2_clock.h:29: error: #error unknown _XTALFREQ" although the #error line in my file is line #34. It seems like FlexC has those header files stored internally and ignores my modified files. This would also explain the strange error from post #963.
To avoid any confusion with files from older versions I deleted the old folder and re-installed in an empty folder. But that doesn't help. I'm using Windows 7.
Don't you need to create a p2ks_clock.h file and include that file.
Mike
I write this directly in the main file:
Most likely it's some problem in the code immediately before
#include <propeller2.h>, because the header file on its own works, e.g. the following program compiles and runs correctly:#include <propeller2.h> void main() { for(;;) { _pinnot(56); _waitsec(1); } }Are you able to share more of your code for us to look at?
Compiler issue:
This use to compile:
__asm volatile { mov i, t loopi mov j, #8 rdbyte x, b loopj test x, #0x80 wz if_z drvl p if_nz drvh p drvh pp drvl pp rol x, #1 djnz j, #loopj add b, #1 djnz i, #loopi }Getting this error:
Mike
It must have something to do with FlexProp not liking being installed in C:\Program files(x86) and the very strange way windows handles access rights. I already had problems with this issue before on a Windows10 PC but not on Windows7. Last time there were files I created by unzipping the flexprop archive that were visible in the windows explorer but unaccessible by FlexProp. This time it seems to be even more strange, There are digfferent versions of the files and the editor sees different contents than the compiler.
I was able to fix that by installing FlexProp on a completely different partition (not C:). I planned to install VSC anyway and use that as IDE front end for FlexProp. The VSC editor is much more user friendly than the TCL editor. Anyway, it was not the source code that was causing the error messages. It now compiles without problems.
You are correct that program files(x86) is a special location, and only setup.exe type installers should be loading programs and executable files in there.
Program Files (x86) is a symlink for certain permission levels. You are correct that an executable running at a different permission level is going to see this area structured differently.
I usually unzip FlexProp to a C:\P2\flexprop\ folder. Kept it short because I don't like to type long paths. It is not necessary to use a different partition, just keep it out of special folders (appdata, temp, windows, system32, etc). When launching FlexProp for the first time on a common Windows 10 configuration, yes you'll get a SmartScreen popup. Yes you click on Run Anyway, and then it sets up the folder access permissions.
Yea, there's a weird layering thing going on with Program Files. If an unelevated process writes to a file there, it actually ends up in
%LOCALAPPDATA%\VirtualStore\Program Files(same for the x86 directory and some other system directories)Something else must have changed in your environment, because that snippet compiles for me (once I embed it into a function with appropriate local variables). Can you share a more complete piece of your code?
Oops, was trying to compile some basic program which was not working but forgot to remove those options from the compile command.
Now it's working again.
Mike
@ersmith
I was moving some code from the Prop tool to Flexprop. Noticed that the || operators and | and ABS are different.
Got error with || flexprop mistook it for ABS. It was a bit confusing until I figured it out.
@pilot : could you show me the code that gave the error? Normally in Spin2 mode FlexProp does understand that || is a logical OR, and I've just checked with some simple examples and they do seem to work.
@ersmith
I will get that to you shortly. Was working on another issue regarding the prop tool. See my prop tool question thread.
Thanks.
Martin
After another "too many flexprops" problem I solved it with a shell script
The script is attached to the Flexprop's desktop icon. No more accidentally run multiple Flexprops.
You should be able to simplify that
ifstatement to something like this (which I haven't tested!):Of course this "p=0" is not needed for anything (left from the previous version which printed the pid)
While trying to search, I often get this instead of the search panel. After closing this error message, the search panel appears but doesn't work.
bad option "tag": must be activate, add, cget, clone, configure, delete, entrycget, entryconfigure, index, insert, invoke, post, postcascade, type, unpost, xposition, or yposition bad option "tag": must be activate, add, cget, clone, configure, delete, entrycget, entryconfigure, index, insert, invoke, post, postcascade, type, unpost, xposition, or yposition while executing "$t tag config hilite -background yellow" invoked from within "if ![winfo exists $w] { toplevel $w wm title $w "Search" grid [label $w.1 -text Find:] [entry $w.f -textvar Find] [ttk::button $..." (procedure "searchrep" line 5) invoked from within "searchrep [focus] 0" invoked from within ".#mbar.#mbar#edit invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tk::MenuInvoke" line 50) invoked from within "tk::MenuInvoke .#mbar.#mbar#edit 1" (command bound to event)Another glitch: ctrl-z (undo) if pressed one time too many, clears the file in the editor window. Then ctrl-y, which should be redo, doesn't work. If there is something in the clipboard, the ctrl-y often inserts the clipboard instead of redo. Xubuntu 20.04.
@pik33 : Thanks for the bug reports. search/replace was bound to too many windows and could get triggered even when the text window did not have focus, which confused things. I've also checked in some fixes for undo/redo. The github repository has those fixes now, I hope to make a binary release "soon".
Is there a way to allocate memory without loading or increasing the size of the program.
For example: uint32_t data[25000];
This will increase the program size by 100k
This does not work unless the heapsize is increased to account for the allocation size which increases the program size.
I want my cake and eat it too.
Mike
Global allocations must be included in the program, for the C standard demands them to be filled with zeroes. Heap being pre-allocated is a bit of a quirk, yes.
The only way to allocate memory that's truly uninitialized is from the stack (local variables and alloca)
I've uploaded a binary version of FlexProp 5.9.10 to my Patreon page (link in my signature). A public release will follow in a few days.
Bless ya! I was really hoping that life would conspire to give you a chance to release a new version.
Off to start some new mischief! 👍
I recompiled a new flexprop several minutes ago: it contains old, "slow" sdmm.cc (which I had to replace immediately as the player "depends on" the new one)
Forgot to update submodules?
I browsed to it using github's web interface and it has the changes (as I expected):
https://github.com/totalspectrum/spin2cpp/blob/efea4d34cca871fc2029bfcc6099e6789a75b9da/include/filesys/fatfs/sdmm.cc
I think Ada's probably right that your submodules weren't updated for some reason.
It seems something went wrong on the machine at the university. Now I repeated the process at home and sdmm.cc seems to be the new one.
There was a mess in the Flexprop directories at the university computer. I simply deleted them (source and installed) and cloned the repository again. Now all seems to be OK: the player compiles and works. This player seems to be one of bigger projects written in FlexBasic
The binaries for flexprop 5.9.10 are up on github. Unfortunately, it seems that Google Chrome on Windows is flagging the file as suspicious because it is "not commonly downloaded". The executable is signed and does not have any viruses, according to all the virus scanners I've tried (and since I built it myself on a Linux machine I think it's virtually impossible for it to be infected by a Windows virus!) so I don't know why Chrome is worried about it. The problem may clear up on its own once enough people have downloaded it. In the meantime, you'll have to manually click on a small arrow to change the "Discard" button to "Keep".