@ersmith The "Edit -> Search" feature in FlexGUI seems to have broken. The search dialog comes up normally, and it allows you to specify the text to search, but when you click "Next", it all goes kablooey.
I think this only happens if you open a file and search immediately. If I click on the tab and do anything at all with the text then search seems to work for me. So there's a bug there, but it's not as catastrophic as search being totally broken .
Edited to add:
There also seems to be a "turnaround" bug on the USB port. If, after downloading code, you immediately issue a "PRINT" statement, the first dozen (or more) characters displayed will be garbage. If however, you put a short delay before the PRINT statement (50 mS seems to work really well for me), then it's fine.
I'm guessing that's a problem with proploader. I'm not too familiar with that code, but I'll take a look when I can.
When using FlexGUI 4.0.2, under Win10 and coding in BASIC for a FLiP:
@ersmith There is some mischief afoot that feels like a "funny". It isn't a showstopper, but if you suddenly run out of projects (snicker) you might give this one some noodle-time:
"D:/Flex2Gui/flexgui/bin/fastspin" -l -O1 -L "./include" "D:/Flex2Gui/flexgui/junk.bas"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.2 Compiled on: Oct 26 2019
child killed: segmentation violation
Finished at Sat Nov 2 11:50:50 2019
There is no way to reliably demonstrate this bug. It will occur in about 1 out of 20 compiles whenever the code size hits more than ~1500-2000 lines. I have never seen this error occur with small programs or when I'm coding exclsively in Spin. This seems to be a BASIC-only bug. It seems to occur more often when using multiple #INCLUDE files, but this may just be an artifact of increasing program size.
Now for the odd part: if the error gets thrown and you do NOTHING but just attempt another compile (ie, dont touch the code, just dismiss the error message and then click on "Compile & Run On P1"), the bug usually goes away. On occasion it will rethrow the error, but that behavior is exceedingly rare.
@JRoark: I haven't seen that crash, but I'll keep my eyes open for uninitialized variables or anything else that might cause that kind of unreproducible problem.
... just dismiss the error message and then click on "Compile & Run On P1"), the bug usually goes away. On occasion it will rethrow the error, but that behavior is exceedingly rare.
Symptomatic of an OS/hardware issue. If you have another computer to compile it with, it'd be worth using that for a while to see if the issue arises there at all.
Symptomatic of an OS/hardware issue. If you have another computer to compile it with, it'd be worth using that for a while to see if the issue arises there at all.
That sounded reasonable so I went with your suggestion. I've now tried on two other machines. Both are running Win10. One is a clunker and it's bulletproof. It never sees that error. The other one is current-generation hardware and the error does occur on that one.
Hi,
I use fastspin in command line in combination with VScode on windows10.
I just updated from 3.9.29 to 4.0.2
Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
I compiled the same files 20 times as test and only 4 times it completed.
Never had this problem with v3.9.29
the program is big. >10k lines.
The program is written for P2 and the command line is:
fastspin.exe -2 -l -O1 --code=hub path\of\program.spin2
If you need more information, please let me know.
edit: the size of the compiled program also changed. From 111360 bytes (3.9.29) to 111648 bytes (4.0.2)
Hi,
I use fastspin in command line in combination with VScode on windows10.
I just updated from 3.9.29 to 4.0.2
Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
I compiled the same files 20 times as test and only 4 times it completed.
Never had this problem with v3.9.29
the program is big. >10k lines.
Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.
Hi,
I use fastspin in command line in combination with VScode on windows10.
I just updated from 3.9.29 to 4.0.2
Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
I compiled the same files 20 times as test and only 4 times it completed.
Never had this problem with v3.9.29
the program is big. >10k lines.
Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.
How can I send you PM or email? (i am not familiar with this forum)
Hi,
I use fastspin in command line in combination with VScode on windows10.
I just updated from 3.9.29 to 4.0.2
Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
I compiled the same files 20 times as test and only 4 times it completed.
Never had this problem with v3.9.29
the program is big. >10k lines.
Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.
How can I send you PM or email? (i am not familiar with this forum)
Thanks to @jef_vt I was able to reproduce the problem, and sure enough it was an uninitialized variable. @JRoark , this may also be behind your intermittent crashes. I'm attaching a beta version of fastspin 4.0.3 which has the fix in it. If you are able to give this a try, please let me know if it works better for you.
Interesting. I’m not sure how this fits into the overall scheme of things @ersmith , but suddenly with the new 4.0.3 version I can use a smaller HEAPSIZE. Typically I’d have to run a HEAPSIZE=4096 and now I can reduce it to about half (ish) of that without throwing errors.
No segmentation violations yet, but the night is young and the code is free and there are adult beverages waiting seductively in the fridge for me. So I’ll let ya know!
There's a preview of the new FlexGUI available at my Patreon page. If all goes well then the "final" 4.0.3 can arrive this weekend, in time for the new P2 eval boards .
When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a FLiP:
@ersmith It appears the GOSUB/RETURN mechanism is broken. The compiler seems to be confusing the RETURN after the GOSUB label with the RETURN for the *function* and aborting prematurely. Or perhaps said differently: "As soon as the compiler hits any RETURN, it exits the function".
This code demonstrates the bug. Cut and copy:
OPTION EXPLICIT
print SillyFunction(10)
'------------------
FUNCTION SillyFunction(limit as integer) as string
dim cntr as long
for cntr = 1 to limit
gosub PrintMe
next cntr
return "All Done after " + str$(cntr) + " loops"
PrintMe:
print "The loop counter value is: ";cntr
return
END FUNCTION
SillyFunction() should execute the PrintMe: loop 10 times and then say "All Done after 10 loops", but it never gets to the "All done" part. I'm thinking this is an ooops.
The GOSUB documentation needs to be expanded a bit. Basically GOSUB is unusable in subroutines or functions, in there it will be treated like a GOTO (because "return" will exit the enclosing function or subroutine). GOSUB is only intended for compatibility with old programs, so I'd really avoid it in any new code you're writing.
The GOSUB documentation needs to be expanded a bit. Basically GOSUB is unusable in subroutines or functions, in there it will be treated like a GOTO (because "return" will exit the enclosing function or subroutine). GOSUB is only intended for compatibility with old programs, so I'd really avoid it in any new code you're writing.
Yep. I dont use GOSUB, but I was playing with some old code and stumbled on it. I restructured the code and moved the offender off into its own function where it belonged, but I figured the "bug" should be escalated. It might be wise to just remove the GOSUB/RETURN functionality from the compiler and docs entirely.
When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a FLiP:
@ersmith Here is a wierd one for ya. There seems to be an inconsistency in how the complier is enforcing variable names that contain a trailing "%". Test case:
print Reverse$("ABCDEFG")
'----------------------------------------------------------
FUNCTION Reverse$(theString$ as string) as string
' Purpose: Reverses the order of all characters in THESTRING$ and returns the swapped string
' Example: Print Reverse$("ABCDEF") would output "FEDCBA"
var idx% = 0
var strLen% = 0
var out$ = ""
strLen% = len(theString$)
' Check for a zero-length string. If found, return empty string
if strLen% = 0 then '<---- ERIC: THIS IS THE CULPRIT (see text)
return ""
end if
' Step thru each character in the string starting at the end and moving to the beginning.
' Copy each char in the reverse order into the output string
for idx% = strLen% to 1 step -1
out$ = out$ + mid$(theString$, idx%, 1)
next idx%
return out$
END FUNCTION
The code above works fine. But if you change "if strLen% = 0" to "if strLen = 0", the complier throws this:
"d: /Flex2Gui/flexgui/bin/fastspin" -l -O1 -I "D:/Flex2Gui/flexgui/include" "D:/Flex2Gui/flexgui/temp.bas"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.3-preview-5d9cb6d5 Compiled on: Nov 7 2019
temp.bas
fmt.c
strings.bas
gcptrs.spin
strlen.c
temp.pasm
Done.
d:/Flex2Gui/flexgui/temp.pasm:312: error: Destination operand too big for cmp
child process exited abnormally
Finished at Sun Nov 10 12:52:01 2019
@JRoark: Ouch, that's a nasty bug. The problem is that the symbol "strLen" is being resolved to the C library symbol "strlen" (since no definition was provided for it in the BASIC code, but it was used in that code). If you replace "strLen" with something like "theStrlen" everywhere then the error message is much more sensible.
When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a P2-EVAL rev B board:
@ersmith It appears that SELECT cant handle an expression or returning value from a function. Here is a cut-n-copy for ya:
print "Silly$ returned: ["; Silly$(1);"]"
'-----------------------------------------
FUNCTION Silly$(a as integer) as string
select case str$(a) '<--- THIS LINE
case "1"
return "It was a 1"
case "2"
return "It was a 2"
case else
return "It wasnt a 1 or 2"
end select
END FUNCTION
If you run that, you'll see that FlexBASIC doesn't like anything except a variable in the SELECT CASE line. If you put an expression of any sort there, the SELECT/END SELECT either goes off into Neverland, or returns random garbage. However, rewriting it this way makes it work every time:
print "Silly$ returned: ["; Silly$(1);"]"
'-----------------------------------------
FUNCTION Silly$(a as integer) as string
dim tmp$ as string
tmp$ = str$(a) 'assign temp variable
select case tmp$ 'do the SELECT using the variable instead of an expression
case "1"
return "It was a 1"
case "2"
return "It was a 2"
case else
return "It wasnt a 1 or 2"
end select
END FUNCTION
An important point: The code that triggered this bughunt worked flawlessly when compiled on the P1. In other words, SELECT CASE worked fine taking the output of a function as its test parameter. But as soon as I complied it and ran it for the P2, that was when the bug manifested itself. Nope. It breaks on the P1 too. My mistake.
When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a P2-EVAL rev B board:
@ersmith It appears that MOD isn't converting non-integer data types to integer prior to mod'ing and instead throws a "internal error unhandled operator". Here is a cut-n-copy for ya:
x = 3.0 mod 2 '<-- throws the error
y = 3 mod 2 '<-- happy camper/works as expected
The error that gets thrown by the compiler is below.
"d:/Flex2Gui/flexgui/bin/fastspin" -2b -l -O1 -I "D:/Flex2Gui/flexgui/include" "D:/Flex2Gui/flexgui/test.bas"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.3 Compiled on: Nov 9 2019
test.bas
d:/Flex2Gui/flexgui/test.bas:3: error: internal error unhandled operator
child process exited abnormally
Finished at Thu Nov 14 12:19:18 2019
Hmmm, MOD seems to be an interesting case, in fastbasic it always seems to do an integer operation. Is that what is desired? I would have expected for example "3.1 mod 2" to evaluate to "1.1", but it seems to evaluate to "1". Doing everything in integer (like fastbasic) would be straightforward to implement. Any objections?
I hadn't even thought that "float mod float —▷ float" or "float mod int —▷ float" would make sense, so I wouldn't miss it. Division with remainder is an integer only thing for me. At least until now. Maybe I need to rethink that?
A>mbasic
BASIC-85 Rev. 5.29
[CP/M Version]
Copyright 1985-1986 $ by Microsoft
Created: 28-Jul-85
38968 Bytes free
Ok
print 3.1 mod 2
1
Ok
█
Maybe I missed it, but is there a listing of key words / reserved words for version 4.0.3 commands? I am interested in using the ADC and DAC smart pin functions.
I hadn't even thought that "float mod float —▷ float" or "float mod int —▷ float" would make sense, so I wouldn't miss it. Division with remainder is an integer only thing for me. At least until now. Maybe I need to rethink that?
A>mbasic
BASIC-85 Rev. 5.29
[CP/M Version]
Copyright 1985-1986 $ by Microsoft
Created: 28-Jul-85
38968 Bytes free
Ok
print 3.1 mod 2
1
Ok
█
Maybe not.
Looks like mbasic and fastbasic agree that mod only operates on integers, so I'll go along with that -- it's actually easier to implement that way too, since there's already code for treating the logical operators that way.
Maybe I missed it, but is there a listing of key words / reserved words for version 4.0.3 commands? I am interested in using the ADC and DAC smart pin functions.
The doc/basic.pdf file has a pretty complete listing of the BASIC language support. doc/spin.pdf documents extensions to Spin (it expects you to already know Spin or to use the Prop1 Spin manual as reference) and doc/c.pdf documents the C support (again, it's just changes from the C standard).
So far there aren't any library functions for dealing with the smart pins, other than the SmartSerial.spin object for doing serial I/O. Contributions in this area are welcome .
Hmmm, MOD seems to be an interesting case, in fastbasic it always seems to do an integer operation. Is that what is desired? I would have expected for example "3.1 mod 2" to evaluate to "1.1", but it seems to evaluate to "1". Doing everything in integer (like fastbasic) would be straightforward to implement. Any objections?
Good points, all.
My understanding from some previous posts was that FreeBASIC was sort of the goal for compatibility. Not really a strict compliance, mind you, but my understanding was that was the general intent of FlexBASIC. If so, then restricting MOD solely to integers is fine and would actually be the expected behavior. But of course if you toss a float at MOD, it needs to accept it and deal with it gracefully.
That being said, I’d also like to have a BASIC version of the C language FMod() function (I call it ModF() in my own library so the compiler stays happy) that accepts two floats as inputs and returns a float. I seem to do a lot of spherical trig, and in these cases PI (or some multiple of PI) always winds-up getting fed to MOD, and you just cant get there from here efficiently with integer scaling and a MOD operator.
Eric,
Pnut treats a RES directive in an ORGH block as an error. Fastspin fails to complain and then makes a group of them all the same address - whatever hub address the assembling is at.
Also Eric, I ran into a problem with use of "res" too in FASTSPIN. For the code snippet below P2ASM worked okay and allowed me to pad out to 64 instructions, but it was no go in FASTSPIN. I'd like this to work otherwise I need to compute a hard coded pad value which changes as I change the code, unless there is another common way that works.
font '64 entry font table stored here
initialregion '...as well as scratch/sync code
' SDTV interlaced sync code (PAL variant coded, NTSC is patched)
interlacedsd 'some different sync code patches
testb fieldcount, #0 wc 'field interlace state
cy if_c call #\hsync 'deal with interlaced field lines
ci if_c xcont m_slim, hsync0 'send a slim half line
' ... less than 64 instructions
res 64 - ($-font) 'allocate remainder of font/scratch area
linebufsize res 1
scanline res 1
rowscan res 1
Eric,
Pnut treats a RES directive in an ORGH block as an error. Fastspin fails to complain and then makes a group of them all the same address - whatever hub address the assembling is at.
RES advances the COG PC and leaves the HUB PC alone (so no HUB space is allocated for it). That's why the HUB address doesn't change. I guess it makes sense to print an error for RES after ORGH, and I've made it do that now.
Comments
I'm guessing that's a problem with proploader. I'm not too familiar with that code, but I'll take a look when I can.
Thanks,
Eric
@ersmith There is some mischief afoot that feels like a "funny". It isn't a showstopper, but if you suddenly run out of projects (snicker) you might give this one some noodle-time: There is no way to reliably demonstrate this bug. It will occur in about 1 out of 20 compiles whenever the code size hits more than ~1500-2000 lines. I have never seen this error occur with small programs or when I'm coding exclsively in Spin. This seems to be a BASIC-only bug. It seems to occur more often when using multiple #INCLUDE files, but this may just be an artifact of increasing program size.
Now for the odd part: if the error gets thrown and you do NOTHING but just attempt another compile (ie, dont touch the code, just dismiss the error message and then click on "Compile & Run On P1"), the bug usually goes away. On occasion it will rethrow the error, but that behavior is exceedingly rare.
Thanks,
Eric
I use fastspin in command line in combination with VScode on windows10.
I just updated from 3.9.29 to 4.0.2
Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
I compiled the same files 20 times as test and only 4 times it completed.
Never had this problem with v3.9.29
the program is big. >10k lines.
The program is written for P2 and the command line is:
fastspin.exe -2 -l -O1 --code=hub path\of\program.spin2
If you need more information, please let me know.
edit: the size of the compiled program also changed. From 111360 bytes (3.9.29) to 111648 bytes (4.0.2)
Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.
How can I send you PM or email? (i am not familiar with this forum)
http://forums.parallax.com/discussion/161418/how-to-sending-a-pm#latest
No segmentation violations yet, but the night is young and the code is free and there are adult beverages waiting seductively in the fridge for me. So I’ll let ya know!
@ersmith It appears the GOSUB/RETURN mechanism is broken. The compiler seems to be confusing the RETURN after the GOSUB label with the RETURN for the *function* and aborting prematurely. Or perhaps said differently: "As soon as the compiler hits any RETURN, it exits the function".
This code demonstrates the bug. Cut and copy: SillyFunction() should execute the PrintMe: loop 10 times and then say "All Done after 10 loops", but it never gets to the "All done" part. I'm thinking this is an ooops.
Yep. I dont use GOSUB, but I was playing with some old code and stumbled on it. I restructured the code and moved the offender off into its own function where it belonged, but I figured the "bug" should be escalated. It might be wise to just remove the GOSUB/RETURN functionality from the compiler and docs entirely.
@ersmith Here is a wierd one for ya. There seems to be an inconsistency in how the complier is enforcing variable names that contain a trailing "%". Test case:
print Reverse$("ABCDEFG") '---------------------------------------------------------- FUNCTION Reverse$(theString$ as string) as string ' Purpose: Reverses the order of all characters in THESTRING$ and returns the swapped string ' Example: Print Reverse$("ABCDEF") would output "FEDCBA" var idx% = 0 var strLen% = 0 var out$ = "" strLen% = len(theString$) ' Check for a zero-length string. If found, return empty string if strLen% = 0 then '<---- ERIC: THIS IS THE CULPRIT (see text) return "" end if ' Step thru each character in the string starting at the end and moving to the beginning. ' Copy each char in the reverse order into the output string for idx% = strLen% to 1 step -1 out$ = out$ + mid$(theString$, idx%, 1) next idx% return out$ END FUNCTIONThe code above works fine. But if you change "if strLen% = 0" to "if strLen = 0", the complier throws this:
I'll have to think about how to handle this one.
Thanks for the bug report!
I do tend to break things in obtuse and head-scratching ways. You should see my garage...
@ersmith It appears that SELECT cant handle an expression or returning value from a function. Here is a cut-n-copy for ya:
print "Silly$ returned: ["; Silly$(1);"]" '----------------------------------------- FUNCTION Silly$(a as integer) as string select case str$(a) '<--- THIS LINE case "1" return "It was a 1" case "2" return "It was a 2" case else return "It wasnt a 1 or 2" end select END FUNCTIONIf you run that, you'll see that FlexBASIC doesn't like anything except a variable in the SELECT CASE line. If you put an expression of any sort there, the SELECT/END SELECT either goes off into Neverland, or returns random garbage. However, rewriting it this way makes it work every time:print "Silly$ returned: ["; Silly$(1);"]" '----------------------------------------- FUNCTION Silly$(a as integer) as string dim tmp$ as string tmp$ = str$(a) 'assign temp variable select case tmp$ 'do the SELECT using the variable instead of an expression case "1" return "It was a 1" case "2" return "It was a 2" case else return "It wasnt a 1 or 2" end select END FUNCTIONAn important point: The code that triggered this bughunt worked flawlessly when compiled on the P1. In other words, SELECT CASE worked fine taking the output of a function as its test parameter. But as soon as I complied it and ran it for the P2, that was when the bug manifested itself. Nope. It breaks on the P1 too. My mistake.@ersmith It appears that MOD isn't converting non-integer data types to integer prior to mod'ing and instead throws a "internal error unhandled operator". Here is a cut-n-copy for ya: The error that gets thrown by the compiler is below.
Looks like mbasic and fastbasic agree that mod only operates on integers, so I'll go along with that -- it's actually easier to implement that way too, since there's already code for treating the logical operators that way.
Thanks,
Eric
The doc/basic.pdf file has a pretty complete listing of the BASIC language support. doc/spin.pdf documents extensions to Spin (it expects you to already know Spin or to use the Prop1 Spin manual as reference) and doc/c.pdf documents the C support (again, it's just changes from the C standard).
So far there aren't any library functions for dealing with the smart pins, other than the SmartSerial.spin object for doing serial I/O. Contributions in this area are welcome
Good points, all.
My understanding from some previous posts was that FreeBASIC was sort of the goal for compatibility. Not really a strict compliance, mind you, but my understanding was that was the general intent of FlexBASIC. If so, then restricting MOD solely to integers is fine and would actually be the expected behavior. But of course if you toss a float at MOD, it needs to accept it and deal with it gracefully.
That being said, I’d also like to have a BASIC version of the C language FMod() function (I call it ModF() in my own library so the compiler stays happy) that accepts two floats as inputs and returns a float. I seem to do a lot of spherical trig, and in these cases PI (or some multiple of PI) always winds-up getting fed to MOD, and you just cant get there from here efficiently with integer scaling and a MOD operator.
Food for thought...
Pnut treats a RES directive in an ORGH block as an error. Fastspin fails to complain and then makes a group of them all the same address - whatever hub address the assembling is at.
font '64 entry font table stored here initialregion '...as well as scratch/sync code ' SDTV interlaced sync code (PAL variant coded, NTSC is patched) interlacedsd 'some different sync code patches testb fieldcount, #0 wc 'field interlace state cy if_c call #\hsync 'deal with interlaced field lines ci if_c xcont m_slim, hsync0 'send a slim half line ' ... less than 64 instructions res 64 - ($-font) 'allocate remainder of font/scratch area linebufsize res 1 scanline res 1 rowscan res 1RES advances the COG PC and leaves the HUB PC alone (so no HUB space is allocated for it). That's why the HUB address doesn't change. I guess it makes sense to print an error for RES after ORGH, and I've made it do that now.