 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 : FW request for CMM2
| Author | Message | ||||
jirsoft Guru  Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
Hi Peter, I found it could make sense to have new OPTION INCLUDE PATH pathname$, in this pathname can be looked for any #INCLUDE file, that can't be found in current path or absolute path given in #INCLUDE. Example: OPTION INCLUDE PATH "/LIB/ #INCLUDE "test.INC" For the test.INC will be first searched in current path, when not found then will be included "/LIB/test.INC". Maybe I'm exception, but I'm reusing some libraries and have them all in the same place ("/LIB/"), then when I forget to change it before upload to GitHub, it will not work for anybody else, who hasn't libraries in the same place. What do you think? Edited 2021-07-15 21:42 by jirsoft Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| mclout999 Guru Joined: 05/07/2020 Location: United StatesPosts: 490 |
Do you mean like the path command for dos where you can list a nuber of directories to search for call files and DLLs? I thought we had something like that already. OPTION SEARCH PATH pathname$ Is that really only limited to running a file and not as a catch-all for programs finding files? I had not yet used it so I was thinking that it was more like the DOS path command. If it is just for running a program it would be a good idea. DOS and even windows still relys on that functionality quite a bit for some programs to find shared DLLs. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
OPTION SEARCH PATH specifies a single directory that will be searched when you use RUN or * without a relative path, e.g. With setting: OPTION SEARCH PATH "/bin/" Then: run "foo" Will first try to run "foo.bas" in the current directory, if it is not there it will try "/bin/foo.bas". Likewise: *bar Will first try to run "bar.bas" in the current directory, if it is not there it will try "/bin/bar.bas". As far as the concept and "limitations" of the CMM2 go this is sufficient for me, I'm not sure *I* need anything else in the regard of execution - except one day I may get around to writing a program specifically to manage the content of the SEARCH PATH directory. Jiri is asking for something else with respect to locating ".inc" files and I'm uncertain what to make of it. Personally I maintain a master copy of my "common library" and then each program that needs it gets its own local copy taken off a specific revision of that master. Any changes to the local copies I feed back into the master but I don't automatically feed from the master back into the local copies and thus I don't have to worry about further developments on the master breaking earlier programs that I am "finished with", Best wishes, Tom Edited 2021-07-15 23:48 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
Exactly as Tom said. For me .INC files have 2 uses: 1. Simply split program (or data for it) to more than 1 file. In this situation I don't need any change as those parts are usually either in the same directory as main program or some sub-directory of it... 2. Libraries with wider use (examples are my TUI.INC, GRF.INC or PropText.INC). Here I would like to have just one copy in common directory and this is reason for this request. Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| William Leue Guru Joined: 03/07/2020 Location: United StatesPosts: 405 |
I agree with jiri: since we don't have real libraries (that is, precompiled binaries), having include files is as close as we can get. It would be awesome to have an include file search path variable of some sort so that we could associate related include files in different directories. -Bill |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Surely INC files are actually part of the main program and should *always* be in the same directory with no exceptions. They must *always* be copied with the program. Anything else is guaranteed to lead to confusion - especially if INC files get updated for use with other programs. You're going to have to track version numbers of every INC file and which program it's used in otherwise. Data files are different and needn't be stored with the main program. If they are then they can be in a sub directory to keep them separate from the program and its INC files. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
I'm fairly certain we've had this debate before in the early days of the CMM2, and I may have even argued for something similar to Jiri's suggestion on that occassion. Now I'm more ambivalent. Two of the "good" reasons for "shared libraries" are: 1. No duplicates taking up hard-drive space - irrelevant, a 32 GB SD card may as well have infinite capacity as far as CMM2 Basic code is concerned (ignoring huge asset/data files in which case the amount of space taken up by code becomes irrelevant anyway). 2. OS only has to keep one copy of the library in memory to serve all the processes uses that library - irrelevant as the CMM2 can only run a single "process" at a time. I think that only leaves an ease of maintenance argument for having a centralised copy and I believe that is far outweighed by the danger of creating our own brand of "DLL hell" (what @Mixtel90 said). That said I don't really care. If the proposed facility existed then it would be easy enough to ignore / not use it with only the slight danger of picking up some "junk" .INC file if you make a programming error in an #INCLUDE statement. Best wishes, Tom Edited 2021-07-16 02:36 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Sorry but the answer is no. It's a lot of coding to do properly for limited advantage. New OPTION, Then code for failed open, switch directory, resolve/error user sillies in the composite filename (e.g.bits of path in both) deal with the fact that FatFS doesn't support relative filenames in exFAT. etc. |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
OK Peter, fair enough., I didn't expect this amount of complexity... Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| ChrisJournoud Newbie  Joined: 12/10/2020 Location: FrancePosts: 20 |
Hi Jirsoft, In your package TUI, when i try LIB_TEST.BAS i have an error saying that the font file cannot be found. It is AtariST.FNT. Where can i found it please ? |
||||
| jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
Hi Chris, I don't know, why was missing. I have added it into GitHub... Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
| ChrisJournoud Newbie Joined: 12/10/2020 Location: FrancePosts: 20 |
Thanks Jiri |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
