The whole reason for the {Spin2_vNN} is so that older sources will work correctly with newer compilers, i.e. to keep OBEX objects working. Making the default be the current Spin2 version would defeat that. Unless of course people put {Spin2_vNN} tags in all of their OBEX uploads, but I suspect there's a fair amount of existing code which doesn't do that.
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
@Rayman said:
@cgracey Do you have an example of OFFSETOF() usage included in the new v53 release?
Glad you got Next/Quit sorted out...
OFFSETOF() can be used in both Spin2 and Pasm, though it is mostly useful in Pasm.
COGINIT(NEWCOG, @pasm_code, @structure_instance)
DAT ORG
pasm_code ADD ptrMemberA, PTRA
ADD ptrMemberB, PTRA
ADD ptrMemberC, PTRA
...some code that uses the ptr's...
ptrMemberA LONG OFFSETOF(structure.MemberA)
ptrMemberB LONG OFFSETOF(structure.MemberB)
ptrMemberC LONG OFFSETOF(structure.MemberC)
@Rayman said:
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
@Rayman said:
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
I use FlexSpin because it supports #include but I only need it in the CON section to include a file that contains auto-generated skip pattern constants. FlexSpin always uses the right source file line numbers when reporting coding errors.
My P2 programs are pure PASM and typically need 150-200 different skip patterns, far too many to create by hand.
@JonnyMac said:
I've done that, too, but would be nice to access constants without using object.constant or object#constant notation.
What if we had a way to define public constants in an object which were ALWAYS given to the parent, without any need for 'objectname.constantname' notation, just 'constantname', as if they had been expressed locally in the parent? Might create a potential name-conflict mess, though.
Yeah, that would be a landmine of trouble. We could make a way to bring in all the constants, though, through some express notation in the OBJ instantiation line.
Comments
Agreed.
The whole reason for the
{Spin2_vNN}is so that older sources will work correctly with newer compilers, i.e. to keep OBEX objects working. Making the default be the current Spin2 version would defeat that. Unless of course people put{Spin2_vNN}tags in all of their OBEX uploads, but I suspect there's a fair amount of existing code which doesn't do that.The new v53 is now posted on the OBEX and on Github.
https://obex.parallax.com/obex/pnut-spin2-latest-version/
A new method OFFSETOF(structure.member) was added and a lingering NEXT/QUIT {level} bug was fixed.
OFFSETOF() is very useful for PASM programs to get offsets of members within a structure that was passed in PTRA via the third term in COGINIT.
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
@cgracey Do you have an example of OFFSETOF() usage included in the new v53 release?
Glad you got Next/Quit sorted out...
OFFSETOF() can be used in both Spin2 and Pasm, though it is mostly useful in Pasm.
DAT ORG pasm_code ADD ptrMemberA, PTRA ADD ptrMemberB, PTRA ADD ptrMemberC, PTRA ...some code that uses the ptr's... ptrMemberA LONG OFFSETOF(structure.MemberA) ptrMemberB LONG OFFSETOF(structure.MemberB) ptrMemberC LONG OFFSETOF(structure.MemberC)Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
I use FlexSpin because it supports #include but I only need it in the CON section to include a file that contains auto-generated skip pattern constants. FlexSpin always uses the right source file line numbers when reporting coding errors.
My P2 programs are pure PASM and typically need 150-200 different skip patterns, far too many to create by hand.
I would like #include for constants. It may not be a good idea for code due to possible naming conflicts.
@JonnyMac one thing I’m trying now is to have a config.spin2 sub object with constants in it. Not as clean as #include but seems to work…
I've done that, too, but would be nice to access constants without using object.constant or object#constant notation.
What if we had a way to define public constants in an object which were ALWAYS given to the parent, without any need for 'objectname.constantname' notation, just 'constantname', as if they had been expressed locally in the parent? Might create a potential name-conflict mess, though.
Yeah, that would be a landmine of trouble. We could make a way to bring in all the constants, though, through some express notation in the OBJ instantiation line.
In my simple world #include for Spin would only allow files with comments and constant definitions -- no var, obj, pub, pri, or dat sections.
Or, since Spin is different, anyway, a new directive:
Sounds good but maybe spin2 extension is better for colors
But this probably already breaks the line # error issue…
Maybe compiler could just include the includes into a new file with some change to filename, open that, and then compile the super version ?
That seems like easy first step ?