Stupid "," error in Propeller Tool
steddyman
Posts: 91
I am trying to compile a few example spin programs (e.g. specie emulator, cgenie emulator) which all compile just fine under BST (on Mac) but when trying to compile them under Windows in the official Propeller tool it always reports the following error on any line (beyond comments):
Error: Expected "," or end of line
Viewing the files in notepad, and the ones that don't work all look to be stretched on one line, like the line endings are incorrect. Yet they look just fine in the Propeller Tool with the line endings shown correctly. But it will always fail to compile them.
This is even with example programs I have downloaded directly from the PC, not involving the MAC. Is there any way to make the Propeller Tool accept the line endings?
Driving me nuts.
Error: Expected "," or end of line
Viewing the files in notepad, and the ones that don't work all look to be stretched on one line, like the line endings are incorrect. Yet they look just fine in the Propeller Tool with the line endings shown correctly. But it will always fail to compile them.
This is even with example programs I have downloaded directly from the PC, not involving the MAC. Is there any way to make the Propeller Tool accept the line endings?
Driving me nuts.
Comments
I think it is files that only have a LF character at the end of the line, rather than a CR/LF. I have amassed lots of these on the forums and every line ending type compiles fine under BST but not the propeller tool.
I need to use the propeller tool because I want to use the serial terminal, and the one in BST always causes the prop to reset when it connects.
You can convert those files to DOS format line endings with the unix2dos command.
Those files will not compile in the legacy Prop Tool as they contain "#define" statements which are supported by BST but not the Prop Tool. You will have to manually fix those up.
Does this converted version of your file compile? See attachment.
So is openspin a better tool? I thought the Propeller Tool was the official tool for Windows so would be the best offering.
Actually spent the last hour trying to get unix2dos installed with my Brew installation post the Yosemite upgrade without much success
http://forums.parallax.com/showthread.php/153921-Open-Propeller-Project-3-Propeller-IDE-V0.1-Package-Available?p=1283880&viewfull=1#post1283880
http://www.parallax.com/news/2014-07-31/interview-steve-denson-creator-open-source-propelleride-elegant-spin-programming
PropellerIDE uses openspin. However I'm not sure how well openspin supports those #defines currently.
PropellerIDE uses openspin. However I'm not sure how well openspin supports those #defines currently.[/QUOTE]
openspin supports #define, #ifdef, #endif, #undef, and probably more...
dgately
This is the project I am trying to compile. All spin files placed in a single directory, compiles fine under BST but refuses to under Propeller IDE.
http://forums.parallax.com/showthread.php/122361-Colour-Genie-EACA-EG2000-emulation
It also doesn't seem to like #ifdef as stated about. The following file gives me an error:
#ifdef screen
I think you have found an openspin bug.
Using someobj#somename does not work when used to specify the array size of a local array variable.
Here is my test code, first a sub object containing a constant definition:
CON test_con = 42 PUB start return 0Then a top level file that uses the sub modules constant in two places:OBJ ts : "test_sub" VAR long x long y long z PUB start | a1[10], a2[ts#test_con] a1[0] := 42 a2[0] := 42 z := x + y + ts#test_con ts.start '#define STOP #ifdef STOP ts.stop #endifThat "a2[ts#test_con]" does not compile. But the other usage does.
Also this test shows use of #define and #ifdef. They work fine. Besure you have a recent openspin version. Mine is compiled from the openspin repository sources last month.
Finally, that cgenie code use the @@@ operator which fails in openspin. I guess it is not yet supported. @@@ was introduce to BST because the normal Spin @ and @@ operators don't work in DAT sections.
Correction: No bug. my test code and most of cgenie copiles fine under a recent version of openspin. Like so:
$ /opt/parallax/bin/openspin.linux cgenie.spin Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2013 Parallax Inc. DBA Parallax Semiconductor. Compiled on Nov 28 2014 15:04:35 Compiling... cgenie.spin |-io.spin |-fatfs.spin |-spi_warp.spin |-vga.spin |-keyboard.spin |-AYcog_V0-22.spin io.spin(621:35) : error : Expected "," or end of line Line: msg_break_ptr long @@@msg_break Offending Item: @If you are on linux the attached openspin executable may work for you else you will have to buidl it from sources:
http://code.google.com/p/open-source-spin-compiler/
Still that pesky @@@ won't compile with openspin any time soon.
What version of OpenSpin are you using? I am using the latest version from the google docs site and it is reported as version 1.00.71 compiled on Oct 12 2014 at 20:32:53. I have BST working on the Mac but I am trying to get a working Windows environment setup in a VM.
I also cannot compile the Spectrum emulator. It is that reporting the error with #ifdef. I've even tried converting line endings and it reports the same:
http://forums.parallax.com/showthread.php/122316-Spectrum-Emulator-(-now-with-SNA-file-selector-)?highlight=spectrum+emulator
Just so we are on the same page I pulled the latest version from github and built it. Sure enough it reports as 1.00.71
Then it compiles most of cgenie like so:
$ openspin.linux -L ../lib cgenie.spin Propeller Spin/PASM Compiler 'OpenSpin' (c)2012-2014 Parallax Inc. DBA Parallax Semiconductor. Version 1.00.71 Compiled on Nov 28 2014 16:05:39 Compiling... cgenie.spin |-io.spin |-fatfs.spin |-spi_warp.spin |-vga.spin |-keyboard.spin |-AYcog_V0-22.spin io.spin(621:35) : error : Expected "," or end of line Line: msg_break_ptr long @@@msg_break Offending Item: @Those # problems are not there.
As I said it fails on the special @@@ operator that is in BST and HomeSpun I believe. But not the Prop Tool. I'm not sure Eric is so keen on adding @@@ to OpenSpin.
If you try and compile speccy.spin from the link above, version 100529-153523 you will see it reports an error on the following error in vgaSpeccy.spin. I don't know if this is a bug:
I can compile vgaSpeccy.spin on it's own like so:
If I move the object definitions around in speccy.spin so as to put vgaSpeccy first like so:
OBJ #ifdef HAVE_VGA vga : "vgaSpeccy" #endif HAVE_VGA fat : "fatfs" #ifdef HAVE_KBD kbd : "speccy_Keyboard" #endif HAVE_KBD #ifdef HAVE_TV tv80 : "tv80" #endif qz80 : "qz80"Then when I compile speccy,spin it has no problem with vgaSpeccy.spin like so: BUT as we see it then fails on compiling TRS80 instead, with a similar error.You should report this as an issue on github.
Will try to pin it down a bit further before raising. Very odd.
I have found this combination crashes the compiler!
#ifdef HAVE_VGA vga : "vgaSpeccy" #endif HAVE_VGA fat : "fatfs" qz80 : "qz80" #ifdef HAVE_KBD kbd : "Speccy_Keyboard" #endif HAVE_KBD #ifdef HAVE_TV tv80 : "tv80" #endifCould be the number of ifdefs, or whatever, is is overflowing some data structure somewhere. Hence the odd behavior when it has compiled most of the files and perhaps a crash. We will see.
openspin has had a lot of testing. It compiles all of obex bit for bit the same as the Prop Tool put not many programs use #blabla so that is new territory for openspin.
The qz80.spin file is 157k in size. Looking at the source, the main structure that drives it is the following code. It looks to me like a limit of 128 directives and 102k total size (though 128 could just be the max line length).
/* * initialize preprocessor */ void pp_init(struct preprocess *pp, bool alternate) { memset(pp, 0, sizeof(*pp)); flexbuf_init(&pp->line, 128); flexbuf_init(&pp->whole, 102400); pp->errfunc = default_errfunc; pp->warnfunc = default_errfunc; pp->errarg = (void *)"error"; pp->warnarg = (void *)"warning"; pp->alternate = alternate; }If you try and compile qz80.spin with openspin -p to disable the pre-processor you get exactly the same error. So it looks like that crashes the preprocessor which then throws an error because the file still has the pre-processor directives in it.
About the second comment, I wondered what board you are using? In my experience bst does not reset the prop when its serial terminal window is opened on a running program, but it does so when the serial terminal window is closed. There are other options for a Mac serial terminal. My own favorite is CoolTerm, cross-platform.
I wondered also about files that have only an LF to end the line. Where do those come from? bst files use a CR, not CRLF nor LF. The bst files look strange and run-on when opened in Windows text but in my experience the Prop Tool opens the file without a hitch. I've had occasional problems with gremlins that come from the Mac, which I dispose of using the Zap Gremlins... option in the Mac TextWrangler utility.
I'm surprised there is such a hard limit on any data structure size.
An awful lot of the worlds coders use Linux. Linux and Unix and BSD use LF (\n) as the line terminator.
See this page for the gory history of line endings http://en.wikipedia.org/wiki/Newline
CR only as line ending is rare and dates back to 8 bit computers and MAC OS 9.
Of course things have only gotten worse since then with the invention of Unicode, UTF-8/16/32. Now it's not just the line endings that make no sense but every character on the line as well.
http://forums.parallax.com/showthread.php/158185-DracBlade-emulated-on-DE-115
I googled i could find lots of people reporting the same under OSX. OS X automatically toggles the DTR line when a modem connection is made. Windows doesn't so it works fine from Windows. I've actually worked around it now by setting one of the sliders on the board to mask the reset line
Digging a little further into this issue with OpenSpin, I've compiled the source and debugged it, and it looks like an issue with @@@ again and not the pre-processor. From what I can work out it is this line that throws the exception:
OpenSpin is a reverse engineered version, or perhaps re-implementation, of the PropTool's source code so it does not have the @@@ operator.
Will openspin ever get @@@ support? Who knows?
Oh well, not usable for me then since most of my interests are with Emulators. Will stick to BST and my reset override switch.
Thanks
As far as I know only BST supports @@@.
I get the idea that Roy did not like the @@@ solution. Which I can understand because it is as ugly as hell.
Let's see what happens.
But those errors and crashes in openspin you posted around post #16 here are openspin bugs that need fixing.
VAR Byte pattern, divide PUB ShiftLedsLeft dira[21..16]~~ divide := 5 repeat if pattern == 0 pattern := %11000000 if ina[6] == 1 divide ++ divide<#= 254 elseif ina[7] == 1 divide -- divide #>=1 waitcnt (clkfreq/divide +cnt) outa[21..16] := pattern pattern >>= 1VAR Byte pattern, divide PUB ShiftLedsLeft dira[21..16]~~ divide := 5 repeat if pattern == 0 pattern := %11000000 if ina[6] == 1 divide ++ divide<#= 254 elseif ina[7] == 1 divide -- divide #>=1 waitcnt (clkfreq/divide +cnt) outa[21..16] := pattern pattern >>= 1otherwise we can't helpWelcome to the forums. As ErNa mentioned, code blocks would make your code easier to understand.
I've edited your post for you as an example. If you click the cog icon top-right of your post, you can edit your own content. And you'll see where & how I've inserted the code tags.
All the best!
If you are saying that the code won't compile, it's because your if/if/elseif statements are not properly indented. Remove the extra space in front of elseif and your code compiles...
Try this:
if pattern == 0 pattern := %11000000 if ina[6] == 1 divide ++ divide<#= 254 elseif ina[7] == 1Your code:if pattern == 0 pattern := %11000000 if ina[6] == 1 divide ++ divide<#= 254 elseif ina[7] == 1 ' does not space-align to the above "if" divide -- divide #>=1If you are saying that there is some other issue, after your code has compiled, please provide the details of the problem.dgately