 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Const and colour shortcuts issues with CMM2 5.05.b5b10
Page 1 of 2   |
|||||
| Author | Message | ||||
realmnm Newbie  Joined: 07/07/2020 Location: AustraliaPosts: 34 |
I had previously been running 5.05.05b4 and my Max-E-Man program was working fine, but when I released it, some users complained that it was not working on b10. There seems to be a couple of issues that I can see so far: 1. I have some data statements at the top of the program that refer to constants that are declared later in the program. This used to be ok, now it isn't, no big deal, I can move the constants to the top of the file, except with OPTION EXPLICIT set, it still gives an error, without it the values of those constants in the data statements are 0. Example: option explicit const one = 1 const two = 2 const three = 3 data one, two, three dim n dim v(3) for n = 0 to 2 read v(n) next print "one = ", one, v(0) print "two = ", two, v(1) print "three = ", three, (v2) 2. Shortcuts for colours now seem to require to be in upper case. Previously it didn't care, now it does. Martin This signature intentionally left blank. |
||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
@Martin, Ran your code under 5.05.05b8 and output from PRINT is correct , with and without OPTION EXPLICIT and with and without OPTION DEFAULT. No errors indicated under any conditions. In the manual (page 19), it appears that unless OPTION DEFAULT is included in your program and if the argument type in a CONST is not specified, using a number such as 1 or 2 or 27 etc. will default to creating that constant as an integer. The array v(3) however will default to floating point unless otherwise specified. Looking at the READ statement on page 76, it appears that READ needs to have arguments the same type as the DATA statement but as indicated above, your DATA statement has integer elements (from the CONST statement above it), so this may be where you are getting a type mismatch or wrong value error? It may also have been fixed in later versions than what you are running. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| realmnm Newbie Joined: 07/07/2020 Location: AustraliaPosts: 34 |
That may be, but with b10, it doesn't work at all. This signature intentionally left blank. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Prior to beta 10, strings in DATA statements that were not enclosed in quotes were being changed to uppercase. This was a bug and has been fixed. That is why your program worked previously but not with beta 10. I am surprised that you could use CONSTANTS in DATA statements. (I get surprised often) You will not be able to simply enclose them in quotes because that will treat them as strings. The colour shortcuts sill work OK as lower case so I expect your problem with them is the same as using other constants in DATA statements. option explicit cls rgb(red) const one = 1 const two = 2 const three = 3 print one print two print three data ONE, two, three dim n dim v(3) for n = 0 to 2 read v(n) next print "one = ", one, v(0) print "two = ", two, v(1) print "three = ", three, V(2) Jim VK7JH MMedit |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
You are spot on there Martin, 5.05.05b8 works perfectly, yet 5.05.05b10 fails with either 0's in the array if OPTION EXPLICIT not included or error with "Error: one is not declared" if OPTION EXPLICIT is included. This occurs on the DATA line so it would appear that DATA is not accepting constants - if the DATA statement is changed to literals, all works fine. OPTION DEFAULT has no impact. Think it might be a bug. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
I see what Jim is saying, "... no CONST in a DATA statement now", it is what it is I guess. Maybe the DATA elements are scanned at load time before the CONST statement is evaluated? Edit: ... some more .... I still think there is a bug because if you change the DATA statement elements to uppercase, the program works. That is, you can use a constant in the DATA statement (for now under b10  ) if it is in uppercase ( just in the DATA statement - it can be declared with DIM of CONST in lower case but must be upper in the DATA statement).'try the following option explicit dim v const abc = 1 data ABC read v print v > run 1 > Doug. Edited 2020-08-18 15:44 by panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
5.05.02 on the Micromite works with the constant identifier in the DATA statement as either upper or lower case (as you would expect). ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| realmnm Newbie Joined: 07/07/2020 Location: AustraliaPosts: 34 |
I think strings should always be quoted, even in DATA statements. You don't use strings anywhere else in a program without quotes, why should DATA statements be any different. I think trying to fix someone not wanting to quote a string has broken all of this. Martin This signature intentionally left blank. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
MMBasic is based on GW Basic TO quote from the GW Basic handbook: The beta 10 change was to make MMBasic comply with this and to be the same as all previous versions of MMBasic. If it has broken something else, that will need attention. I don't know if it was ever intended that CONST be used in data statements, it certainly doesn't agree with GWBasic: Jim VK7JH MMedit |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I've asked Geoff's view on this. IMHO the original code in Max-E-Man worked by exploiting an unintended feature (bug?) in MMBasic. As per the manual chase and scatter are literal strings exactly as if you had written them "chase", "scatter" so the code shouldn't have worked in versions before beta10. The workround in beta10 is to convert them to uppercase but this is still exploiting the unintended feature Edited 2020-08-18 17:34 by matherp |
||||
| realmnm Newbie Joined: 07/07/2020 Location: AustraliaPosts: 34 |
Aaaah, so it is consistently inconsistent.  Martin This signature intentionally left blank. |
||||
| realmnm Newbie Joined: 07/07/2020 Location: AustraliaPosts: 34 |
You can see why this was done, it means you only have one reference for the values. I could put in the actual values into the DATA statements, but that means the data is a lot harder to interpret from a user point of view, and can lead to simple errors when creating the data, which could be harder to debug. Also I didn't know I was exploiting anything, it just seemed like a logical thing to do. Also this has also had the I'm sure unintended issue or requiring the colour shortcuts to now be upper case. Edited 2020-08-18 17:45 by realmnm This signature intentionally left blank. |
||||
| flip Senior Member  Joined: 18/07/2016 Location: AustraliaPosts: 114 |
Hi all, My 2c, IMHO if I get to vote...is can we treat data elements like virtually all the rest of MMBASIC, and explicitly require double quotes if you want a string literal Also, being interpreted, this gives the opportunity (like many other parts of MMBASIC...e.g. DIM statement) to accept formulas so for example, numeric literals: DATA 1E23,100,1.5 and string literals: DATA "String","For","Function" Nice to have / keep Variables/Constants,Functions etc (perhaps processed as per EVAL ?)...this would give fantastic flexibility ... onus is always on coder to use appropriately. So its like CSV export but string literals must be in quotes. Please take this into consideration (along with simplicity/elegance of coding the MMBASIC engine of course). Regards Phil |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Could Peter or Geoff perhaps expand on where and how CONST is intended to be used? My understanding is that it effectively is a method of equating a textual name to a numeric or string value eg. CONST pale_blue = rgb(200,200,255) or CONST home$ = "Bega" As Martin indicated, he used it to simplify understanding of his code. I note that GWBASIC does not have a CONST command (as far as I can see) so is the intention in MMBASIC that anywhere you might use a numeric or string literal, eg, 1, 3, 45, "hello", you could in fact use the more usefull and understandable pre defined CONST name? Doug Edit: So if my understanding above is reasonable, why could you not have CONST numeric or string variables in a DATA set of elements? We now have the criteria that all literal string elements in DATA statement must be quoted thus there would be no conflict. My take is that this ability is not in conflict with GWBASIC but could enhance readability of programs. D. Edited 2020-08-18 19:12 by panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
No this isn't the case. CONST actually creates a variable but one that is marked as non-changeable so if you try to change it you will get an error DATA should only support literals and the confusion above is that it seems to also support variables/constants although this isn't documented as a capability and certainly isn't in the GWBASIC specification. I assume the reason it can do this is because it allows arithmetic expressions as per the manual (5 * 60) and that uses the generic variable handling code to evaluate the expression. |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Thanks Peter, I understand. Would it be simpler for CONST to in fact purely do a replace at load time rather than use up a variable? Please excuse the simplicity of my question as I have no understanding of how my suggestion might be implemented- purely a thought on how one could essentially do something similar to the C #define ( again, I do not have much knowledge of C but I note how #define appears to be used there). Thanks, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I've discussed this with Geoff and the proposal we both support is as follows: Add to the manual entry for the DATA command as follows: realmnm: if you make this change to the data statements in Max-E-Man it should run fine on V5.05.05b10 and earlier versions and at the same time MMBasic will maintain compatibility with other Basics in its treatment of implied strings in DATA statements Edited 2020-08-18 22:14 by matherp |
||||
| realmnm Newbie Joined: 07/07/2020 Location: AustraliaPosts: 34 |
I can live with that. Thanks for taking the time to work it out. You should probably change the manual for the colour shortcuts to mention they need to be in uppercase as well, or make them work as both. Thanks, Martin This signature intentionally left blank. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
It is only if they are used in DATA statements that this will apply and I think that is covered by the proposed statement |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1132 |
So if we want an uppercase string in a data statement, we must enclose it in double quotes? Visit Vegipete's *Mite Library for cool programs. |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
