Edit: Version 0.17
* presence of @@@ disables duplicate object elimination
brad@bklaptop2:~/Objects/FemtoBasic_2008-02-28/FemtoBasic$ mono ~/Desktop/homespun017.exe FemtoBasic.spin
Homespun Spin Compiler 0.17
comboKeyboard.spin, line 645: Expected local label
shift2 byte $22, 0, 0, 0, 0, "<_>?)!@#$%^&*(", 0, ":", 0, "+"
I wouldn't call the caret positioning a bug. It points to the start of the token ( a string ) which isn't as expected. That it doesn't take the string as it did the one before it looks like a bug.
Brad -- @@@ disables bytecode based duplicate elimination. The way Homespun works is it knows what order the objects should be in memory but not where, then it compiles the first object at address 0010, now knows how long it is, compiles the second object putting it after the first, and so forth.
Then bytecode based duplicate elimination occurs, which can move objects around in memory to close up gaps caused by object elimination. Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
Filename-based duplicate elimination occurs much earlier in the process.
Maybe your compiler does things in a different way and can avoid the problem.
Thanks the bug report. I'm vacationing in San Francisco this week, so updates will be sporadic at best.
These additions do not create code and should just be ignored by the compiler and not generate errors etc.
Basically ignore anything that starts with End and has a white space following.
#Region - and anything else on this line.
Currently all "Spin Objects" are defined as separate files.
The idea here is to have the objects defined in a single file as well, let me know what you think about that.
Before @@@, this didn't matter, but now some object is going to depend on living at address xxx, and moving it somewhere else will cause much pulling of hair.
<LI>#define (simple text replacement)
<LI>#ifdef/#elseifdef/#else/#endif (conditional compilation)
<LI>improved memory dump (including crude Spin bytecode disassembly)
There are those of us who like to have our control constructs delimited with braces or keywords rather than relying on indentation.
I've many times managed to screw up program fragments when copy and pasting them around within a project or between programs as the indentation levels did not match. It's even worse pasting into a different editor or platform etc.
This must be an issue for many as otherwise cntrl-I would not exist in the Spin tool.
So I would welcome Endxxx statements, especially if they were NOT just ignored but actually did what they say.
Nice.. really, really nice.. gives me something to aspire to [noparse]:)[/noparse] (Or imitate!)
Fantastic - I have just checked the listing output - it is perfect for doing full debugging back to source level, both in pasm and spin.
If you change the grammar to that degree, then it will cease to be SPIN really. If you start to implement major changes to the grammar like that, how do you differentiate between Parallax compatible code and code with "relaxed" whitespace requirements but non-spin block styles?
One which often gets me is - "repeat var from start to finish"
Why not - "repeat var := start to finish" ?
or, as I always use until the syntax error - "for var := start to finish" ?
Which is a pain because, AIUI, arraysize-1 is computed at runtime. Maybe even on every loop.
I suppose the answer is to use the 'constant' operator, though it's an optimisation I'd expect the compiler to do on it's own.
[noparse][[/noparse]sorry .. indentation lost. You know what I mean .. ]