 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 : Micromite Library
Page 1 of 3   |
|||||
| Author | Message | ||||
| paceman Guru  Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
This is a continuation of another thread that deviated into discussion of a Micromite code library. The relevant library posts have been transferred below. Glenn (Administrator) has advised that this is the only way to transfer posts from another thread. |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
|
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
|
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
|
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
|
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
|
||||
Gizmo Admin Group  Joined: 05/06/2004 Location: AustraliaPosts: 5116 |
I'm happy to host a document register on the main site if someone else can maintain it. Couple of ways we could go. Either someone puts together a bunch of documents ( PDF preferably ) and files, with a separate index page, and they email updated files and index page to me, which I'll put online as needed, or I create a system from scratch where a administrator or two can log in and update the library themselves. The first option would be prefered, I'm time poor at the moment. Someone would have a document template, which can be edited and saved as a new page, and then saved as PDF to go online. They would send me the new/updated PDF and a updated index file. I would then upload it to the site and update the index page, so when someone clicks on a topic, it links to the relevant PDF or file. I would like to put together a library app from scratch, but as I said I'm time poor. The biggest job with any new system is planning it, writing the code is the easy bit. If there is a existing system out there that would work for our needs, or someone can document how it should work, let me know and I can have a look at it. Just an idea. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Well, OK since I put the thread up maybe I should make a suggestion. There are several generous offers in the posts above and agreement that we need a Micromite library to hold both MMBasic programs and CFunctions. Peter (G8JCF) has offered to be CFunction "Editor" and depositry (as per the 5th Dec, 9:14pm post above) and it seems to me that: a) doing that would be a major job that no-one else is likely to offer to do. b) he is best qualified and the logical person to do it. Since Geoff, and I think all of us, would like all the Micromite code (MMBasic, CFunctions, snippets) in one place it would be great if Peter could also be the depositry of the "Basic-only" code. Whether he's happy to do this and under what conditions, I guess we're about to find out. 
Hugh Buckle has put a lot of work into the Maximite MMBasic library as Geoff has pointed out "tested most programs, chased up details, classified and indexed submissions" and it's a big ask for Peter to also do this for the Micromite MMBasic programs. Maybe it could be "automated" a bit via a simple "submission" form or something to make it straight forward, though that obviously doesn't test things. If the form required a link to the TBS thread though that would help and if a user needed clarifications he could then contact the person that posted the program &/or information in the first place. This thread probably needs to be aired a bit longer but what are the current thoughts? Greg |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Is this the kind of thing people have in mind (maybe hosted on TBS if possible) MMBasicII Library see OLEDI2CLib.bas for an example of a wee bit of 'Editorship" having been applied to minimise name-space clashes for Global Variables, and a slight moving around of the code so that the TestSuite code lines are placed at the end of the program for easy deletion. (would this kind of editorship be acceptable to Library contributors ?) Peter The only Konstant is Change |
||||
| Gizmo Admin Group Joined: 05/06/2004 Location: AustraliaPosts: 5116 |
Peter that's nice and neat, no fancy graphics or large files. Spot on. The format is good because its easy to search, and easy to stick into a database at a later date. Once in a database, you can add a few nice features like order by column, better search, etc. Might have to format the file names so less chance of getting duplicates, like SerialTxt_1_0.bas for the version 1.0 file I would be OK to host something like that. I've recently found out my monthly bandwidth for the web site has gone up. It was only 30Gig originally which was often exceeded, but now its like 10 times that so I'm not as worried about exceeding my monthly limits. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
Oldbitcollector Senior Member  Joined: 16/05/2014 Location: United StatesPosts: 172 |
+1 Peter I can see this needing some "categories" at some point, but exactly what I envisioned as well. My Propeller/Micromite mini-computer project. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Glenn Thanks for the positive feedback. Before you responded, I was thinking about a page-per-item approach - like man pages on Unix, where the index.html page simply had short links to the page for each item, so that the page could contain a lot more information. However that would of course increase storage size, and make database'ing the pages a bit more complicated, and materially increase the workload for the Editor/Librarian/Curator. Being able to search and order by column would be really nice especially as the number of items grows. Let's see what others think. Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@OldBitC Just Added The only Konstant is Change |
||||
| Gizmo Admin Group Joined: 05/06/2004 Location: AustraliaPosts: 5116 |
If you wanted to build the library in plain clean html, I can throw it in a iframe or use a bit of AJAX to display it within a TBS page. The TBS page "frame" would have the usual, like a menu and link back to main page, plus a couple of adverts but not in the middle area where the library content will be displayed. Use tables, keep all links relative, and have a couple of sub folders, like "CFiles", "BASFiles", "PDF", etc. That will keep it transportable. Also ideally use a style sheet to keep the fonts consistent. If the html is clean, its not to hard to import it at a later date into a database. Or, if someone has MS Access and could use that to create the library in a table, then it would be easy for me to display that online. Displaying a access table is easy, its writing a web based administration back end that would take a bit of time to develop. A Access database would mean we could jump straight into adding column sorts, filters, etc. The "librarian" would just need to email the updated table to me plus any new files. Another option is to create the table in Excel, but a little more work to get set up right and longer to get a update online. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Glenn The library code is all simple HTML and positioning is by tables, and indeed the data is held in folders/subfolders 
As for the Database options, I could do an Excel file, but that's about as far as I could go - it's been too many years since I did dB work (30). Peter The only Konstant is Change |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10194 |
I think this is an excellent initiative and excellent idea re the "test suite". Also this approach allows any variables used by the main program to be declared as LOCAL. Then the only variables defined as DIM would be true global variables I don't think we need a separate cFunction library as per Grogster's thread. All cFunctions should be provided with a simple "test suite". I'm happy to modify my code for inclusion as per any sensible set of library guidelines. My biggest concerns for easy reuse are issues around OPTION DEFAULT, and OPTION EXPLICIT. I think OPTION EXPLICIT should be mandatory. In a perfect world I would prefer that code for inclusion would also be OPTION DEFAULT NONE. The only issue with this is the space that multiple "AS INTEGER" definitions take up. My recommendation would therefore be that only OPTION DEFAULT NONE and OPTION DEFAULT INTEGER are acceptable. FLOATs, which I think should become the exception, would then have to be explicity typed. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Peter M Phew, I wasn't quite sure how you would take my editing your code :) but I'm glad to see that you are up for producing 'neutral' libraries - thank you Re Global Variables. ALL my programs have a SUB MAIN so that the only variables which are declared with DIM will be true Global Variables, ie why Dim and Local are so important to be used correctly. Also in Libraries, I always declare any Global variables as part of the Libraries INIT function, eg see I2CLCDLib and use the syntax Libname_ or Libname. to prefix such Global variables to minimise name space clashes Re Library Function/Sub names, again, ideally all Function/Sub names in a Library should be prefixed with the Library name to mitigate against name space clashes, eg OLEDI2C.Init, I2CLCD.Init etc Re Constants, MMBasic constants are always Global (Geoff isn't going to introduce Global/Local constants, we've already had that discussion  ), so the potential for namespace collisions is extensive, again I would recommend that ALL library specific constants are prefixed with the Lib name, eg Const OLED.ScrnWidth = 128
Re TestSuite, this structure works well because it a) provides the programmer/author with a test bed with which to test out their code, b) demonstrates to the would be user how to use the library. Placing at the end of the code allows for easy delineation and subsequent removal by the end-user. Re Option DEFAULT, this is going to need some thought, but IMHO, I believe that ALL library variables must be EXPLICITLY declared, eg Dim OLEDI2C.I2CAddr as Integer, and thus libraries should NOT declare Option DEFAULT. If user programs want to use the Option Default construct they would then be free to do so unconstrained by the Library Re I2C, In general Libraries should NOT OPEN the I2C bus because other libraries might try to do the same, but more importantly User code could quite legitimately issue I2C Open constructs. I'm not sure how gracefully MMBasic handles an I2C Open to an already open I2C bus, perhaps MM.I2C could return the state of the I2C bus to permit libraries to skip I2C Open statement, and/or are there other techniques ? Would it be OK with you if I complete the editing of your OLEDI2C library so as to produce a good example of how (I think) a library should be published, and then we can all debate around that example library ? Peter The only Konstant is Change |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10194 |
Excellent approach, fully agree Agree in principle of course. My only issue with this is space while loading the program. I don't think it is reasonable to expect everyone to use a pre-processor and a #define approach. My OLED routines already have to be "crunched" to load reliably. Agree other than the space issue Absolutely agree this approach should be adopted. Agreed, therefore library routines and test suites should use both OPTION DEFAULT NONE and OPTION EXPLICIT to demonstrate that all vaiables are both fully defined and typed This is easy to test for as per my usage in the DS3231 routines. sub DSSettime local clock$ local i local i2clook=peek(WORD &HBF805000) AND &H8000 if not i2clook then i2c open 400,1000 i=rtcsetDS(clock$,time$,date$) I2C write &b1101000,0,len(clock$),clock$ if not i2clook then i2c close end sub Absolutely
The only thing all this misses out is how to handle complete programs which users wish to contribute. I think there should be a section for full programs to be contributed that may or may not include library routines (which would be included separately). Peter |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Peter The issue of program size is a thorny one as always when it comes to the tradeoff of Readability & Quality vs Memory Footprint. Personally I take the view that the code should be self-documenting, neutral etc, and that if a particular user needs to compress the size down, then that particular user needs to adopt measures such as using #define to replace constants and crunching long symbol names into short ones. If people don't use MMEdit, then crunching becomes a real tedious exercise, whereas with MMEdit, crunch happens automatically and transparently every-time one downloads code to the uMite. Re Option Default None and Option Explicit - these statements should be used by the library developer to ensure that their code is as defect free as possible, eg usually declared in the TestSuite, but should not be present in the Library itself, thus granting the end-user "the maximum freedom to make a mess of things !" - I jest of course, but the library should not try to impose a particular coding style on the end-user even if it would be in the end-user's best interests
Re I2C, EXCELLENT, I'll give that idea of yours a whirl, even better perhaps write a CFunction IsI2COpen Thanks for the permission, hopefully you will like and approve of the results. As for whole programs, I don't see why that wouldn't just fit in, I think we'll have to change the Type column to have 3 values, CFunc, Lib, Prog ? Peter The only Konstant is Change |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Wow, that all seemed to work  , thank you very much gents, especially obviously Peter, Peter and Glenn. You all seem to know a blo...y site more about this than me so I'll stand clear!
Couple of things though - of course , written in the Royal "we":
- I agree we definitely need to cater for full programs. - Will we also cater for MMBasic subroutines. - What about .JPG files? There's a few of them in the MMBasic library and they can be handy but they might be an issue for Glenn. - Can we include links to the appropriate threads - assuming there is one which is usually the case. Thanks again and over and out
Greg |
||||
| Page 1 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
