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 : MMBasic for Windows - alphas
Page 7 of 12 | |||||
Author | Message | ||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7034 |
I'm not sure that it's at all wise to allow the user to get out of MMBasic in any way whatsoever on a PC. It's like giving them root access to a linux box. Very bad. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
I don't think it's like that at all, and in any case it can't be any worse than any other programming language (i.e. "C") and peeking would still be restricted to within the MMBasic processes own virtual memory. In any case the current discussion is not about calling C code from MMBasic it is just about whether Peter can be persuaded to implement sufficient CSUB support so that they could be used as data blobs like they can on the other recent MMBasic platforms ... including MMB4L . Best wishes, Tom Edited 2022-02-22 23:02 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
The answer is no. It is a misuse of the command, confusing to users and illogical to document. It is so easy to load binary data from file that it makes no sense to create a separate mechanism. Read also does the job perfectly adequately and with some sensible naming of restore points should not be an issue with include files. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
Fair enough, but you recognise that LOAD DATA is not usable for a library to independently load its own data because a .INC file doesn't know where it is located ... or to put it another way the .INC file has already been inlined and that context is lost by the time any LOAD DATA command within is executed. I note that PureBasic can IncludeBinary data but that would also require you to support .INC files including other .INC files (which isn't particularly difficult), but I'm not trying to get you to add new features to MMB4W beyond those supported by the CMM2, afterall the goal is compatibility. You are the one who taught me how to do it . Best wishes, Tom Edited 2022-02-22 23:23 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
No, but the inc file knows where the original bas file is located and can reference and data from that |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
No, but the inc file knows where the original bas file is located and can reference and data from that I believe that makes an assumption that the .INC file is only being used by one .BAS file which may not be the case for a true library. Unless you are proposing that the user writes code to trawl the .BAS file and parse its #INCLUDE statements. Best wishes, Tom Edited 2022-02-22 23:31 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
I think you could make it work by adding support for a preprocessor macro (perhaps two, one that includes the filename and one that doesn't) that expands to a literal string containing the location of the .INC or .BAS file currently being processed. Either way I will probably hold my nose and switch to using DATA statements in my "crypt.inc" code . Best wishes, Tom Edited 2022-02-22 23:56 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
There are no true libraries - this is MMBasic . INC files will inevitably be duplicated and therefore it is not unreasonable to duplicate any data or if you are really worried about it use DATA statements in the inc file with a restore point name that includes the INC name. Remember, if you provide a composite executable to a user they need all the components and can't be expected to "install" inc files in any specific known location otherwise you are just making life too difficult for them. They just want to unzip a package wherever and have it run without doing anything else. I remember this was discussed before and my recollection is that the duplication of inc files, however unpalatable for the purist, was a necessary evil for MMBasic Edited 2022-02-23 00:02 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
I'm not getting anywhere here am I? I think I'll open up another front of operations . How about an MM.INFO() that could read the value of the global DATA pointer into a variable and then a variant of RESTORE that could make use of that. Then subs could be written that make use of DATA but restore the state of the global DATA pointer when they exit. Note I'm only really interested if this comes with a commitment to backport to the CMM2 and PicoMite. Best wishes, Tom Edited 2022-02-23 00:10 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
Sorry no, but I really believe you are looking for a solution to a problem that only exists for you |
||||
jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
For me will be perfect something similar to SEARCH PATH but for .INC files (SEARCH INC PATH?). Then you can load .INC file from same path as .BAS file and when is not here try it from SEARCH INC PATH... So I can have one directory as library, set SEARCH INC PATH with it and all my COMMON .INC files have just in one place. Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
Possibly, but I'm flexible and I'll work around it somehow. If I can be frank the flipside of your comment is that you don't appear to be eating your own dogfood . Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7034 |
If you can #include a file that is a set of DATA statements then the first one could be a list of the restore points. You could have different programs load the same file, some may use all the restores and others only selected ones. If it works like the PicoMite you can have calculated relative Restores too. Very nice for adventure games where the restore point is your room number. :) Or you can pack binary data into strings - just don't try to output them. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
V5.07.03a7 MMBasic.zip New temporary option OPTION CONSOLE REPEAT ON/OFF When set it copies all Print and output to the console. It is reset to off when a program is run MM.CMDLINE$ implemented OPTION DEFAULT PATH errors tidied up MM.INFO(exists dir dirname$) implemented to complement MM.INFO(exists file fname$) Current MM.INFO are: SOUND MAX PAGES PAGE ADDRESS FRAMEBUFFER DIRECTORY (same as CWD$) EXISTS FILE EXISTS DIR OPTION AUTORUN OPTION EXPLICIT OPTION BASE PROGRAM AUTORUN DEVICE (same as MM.DEVICE$) DEFAULT PATH VERSION (same as MM.VER) VARCNT CURRENT FONTWIDTH FONTHEIGHT FILESIZE FONTCOUNT (how many chars are available in current font) WIDTH HEIGHT HPOS VPOS FCOLOUR BCOLOUR FRAMEH FRAMEV WRITEPAGE FONT ERRNO ERRMSG OPTION BREAK Edited 2022-02-23 02:07 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
If it works like the PicoMite you can have calculated relative Restores too. Very nice for adventure games where the restore point is your room number. :) Doesn't solve the problem ;-) 1. DATA works by maintaining a global pointer to the next piece of DATA to be READ. 2. RESTORE can set the pointer. 3. There is no mechanism for user code to read the pointer, only the DATA it points at. The result is that if I write a piece of code that calls a SUB or FUNCTION (potentially from a 3rd party, i.e. a library) then it may change the global pointer and there's nothing either the caller or the callee can do about it except religiously ensure that every set of READs starts with a RESTORE and that within a set of READs they don't call any code out of their control which might change the global pointer. It's not an MMBasic specific problem it's just a flaw in the whole BASIC DATA/READ feature that is irrelevant for small atomic single-developer programs. Anyway I've moved past the point of expecting Peter to do anything about it. I knew there was a reason I was avoiding involvement in MMB4W . Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
Thank you Peter I'll take it for a spin in the morning. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
I don't suppose there is any possibility of you calling that "DEBUG" or "CONSOLE PRINT" so it doesn't conflict with MMB4L's family of CONSOLE commands ? ... I guess I could change the MMB4L keyword to TERMINAL. Best wishes, Tom Edited 2022-02-23 02:05 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9425 |
I started with DEBUG but everyone uses debug as a variable so discounted that. I'll change console to something else in the next release Going back to the READ issue. How about READ SAVE/RESTORE? These commands could be used by an INC file to save the current datapointer then do the local read, then restore it after. That way the INC could know it was being a good citizen. This could then be included in the PicoMite and CMM2 next releases Edited 2022-02-23 02:23 by matherp |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7034 |
@Tom Hmmm... BASIC was never designed or intended for anything else but the user program to mess with the global DATA pointer. For a start it's not safe - you could make it point anywhere. It's one of those things, like changing RAMTOP, that you just don't do from within your program. The BASIC view is that if it gets changed from outside the program then something has crashed. I bet you write self-modifying code just to upset people. :) Edited 2022-02-23 02:32 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4103 |
Thanks Peter. Though I'm still open to changing to TERMINAL, if anyone with an interest in MMB4L is in favour of that. That sounds ideal, so the workflow would be something like READ SAVE RESTORE foo READ variable[, variable]... READ variable[, variable]... READ variable[, variable]... READ RESTORE ? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Page 7 of 12 |
Print this page |