Embedded Files
*************************************************************************************
Major Tom to Source Control... (06/13/2014)
With the last blog entry, I had decided to take a break from MShell for a while so that I could take a fresh approach to the code and maybe even do a little re-writing, but I couldn't resist just a couple of more edits.... And of course, I broke it! Not severely, just a couple of functions no longer work as they did.
In trying to recover my last "stable" sources, I realized that they also had a few of the "offending" edits as well before I saved them to my archives. So I had to go back to an old MShell source archive that didn't include my last "stable" edits, and between the two archives, figure out what was stable and what was not. This is about the 20th time this has happened with MShell alone, not to mention how many times it's happened with the other OS-9 projects. So now I AM going to take a break from MShell... to write a "Source Control" program which will save my sources each time I compile them... automatically!
This was originally planned to be a part of the future "OS-9 Source Repository" module for MShell, but the immediate need for source control has brought this project to the front of the list. At this time, I will only try to get some sort of "source control" working and not worry about the "Source Repository" so much. I will keep in mind that this must eventually fit into an MShell module as to keep the sources in the MShell framework. But for now, I need a source control program.... and fast!
The idea is a source control system based on either a CRC of the source file, the last modified date, or both. My compiler system already recognizes when a file is up to date and does not need to be compiled, so I need to incorporate this function into a source control system. I want the system to (before compiling) check the CRC/last modified date against the source control project records, to see if the source has been modified since the last compile. If not, the last "copy" of the file becomes the current (in the source records). If it has been modified, it will be copied to the repository (local) with the new checksum as a file extension. I haven't quite worked out how I want to go about this yet, but have some good ideas. This would give me a record and archive of every file in the project for each new build. The source control system will be incorporated into my custom OS9 C compiler system so that every time I compile a source, it gets checked and saved (if needed), and a record kept of the vesion numbers for each compile. This will eventually take up a lot of HD space, and since I use the Vcc Coco 3 emulator and DW4 for my developement system, I can set up a separate VHD for the project files to be stored. My work VHDs are about 96 meg in size, so that would give me quite a bit of source archive space per project. And since I run Vcc overclocked at about 72mhz, the extra file copies will only take a few extra seconds in the compiling process. I may waste some drive space, but in the end I'll save a lot of time. I may even write a simple GUI for a standalone version of the source control system so the user can set drives, paths, filenames, and version number for starting a new project.
If I can work out a simple versioning method that can be used for the file extension, then this would make it easier to implement in my "internet updater" for a better update method. Currently, the updater checks the project version number, then compares that to a version number from the updater site. If there's a difference, the complete project is downloaded. Implementing individual file versioning would make it possible for the updater to only update the files that have changed and not the whole project. This will also make it easier to work all this into the "OS9 Source Repository" project as well.
Since this will eventually become an MShell module, I will keep the progress of this project within the MShell blog. I see no need to start another blog for the Source Control project by itself. So, keep watching here for progress on the Source Control project... Another "first" for the Coco and OS9 :-)
B.P.
*************************************************************************************
From Sound to Source.... (06/16/2014)
In starting the Coco Source Control System, I needed a GUI for the program frontend. I've used the "Sound Chaser" GUI as a templet since Sound Chaser already has a good, stable directory structure and the ability to filter files by their extensions. Also, SC's HW text GUI structure is fairly simple to convert to the graphics format used by MShell when I get ready to implement CcScS into that project.
The first thing on the list is to decide how I want to display the data. I have decided on a two panel display similar to MShell, but in HW text mode. With 2 panels, I can display the project work directory with it's source file in the left panel, and the selected filenames for the project in the right panel. I am making the items in the right panel editable so that files can be added, deleted and renamed. The renaming may be needed as there will be a limit to filename size due to the addition of a checksum to the extension. OS9 only allows 29 characters per filename and (so far) I plan to use at least a 10 character checksum extention. That would only leave 19 characters for the filename. I have seen very few source file with filenames that large anyway.
Each source "project", will have a "Project Name" folder, then sub-folders for each revision archive. Somthing similar to this:
- MSHELL.PRJ
- MSHELL.0615721120
- source_a.c.0615721120
- source_b.c.0615721120
- source_c.c.0615721120
- MSHELL.0616721121
- source_a.c.0615721120
- source_b.c.0616721121
- source_c.c.0616721121
- MSHELL.0615721120
As you can see, only the files that change get the new revision number. This way, you can trace source revisions back to their last changes by searching the different revisions, which is a function I hope to include in the interface.
In the "project" panel of the GUI, I will be displaying the project name and current working revision number so you will always know which revision is in your work directory. Also, in the work directory, there will be stored a file in which contains a list of the location of the revision archive and all it's contents. As long as this file is updated each time something is added to the archive, it will make searching the archive less painful. It will also make reverting to an older revision a simpler task. Just specify the revision and it will be copied into the work directoy.
CcScS as it stands now, already has MShell's virtual memory buffers in place and working. So far, I'm using two such buffers, one for the work directory listing and one for the project list. I may add a third buffer for general use. The virtual memory buffers is probably one of the best things I've discovered for OS9 programming. It allows me to store massive amounts of data without using the project's 64k workspace for data arrays. I haven't decide yet if I'm going to use the "fragged sub-routine" technique yet. That will be implemented if I start to get low on memory in the workspace. This would allow me to load in unlimited sub-modules as needed just as MShell and Ultimuse3 do.
As this comes together, I will be posting more about the capabilities and methods behind the "Coco Source Control System", a much needed utility for OS9 programmers :-)
B.P
*************************************************************************************
No Permission to enter... Next please... (06/28/2014)
In working on the "Source Control" system, I had to drop back into MShell and implement an OS9 to OS9 copy feature. This was needed to be able to copy source files from the working directory to the source archives. In doing this, I had to remove the "just added" search feature from MShell as I was running out of memory. I will work that back in later as I move more subroutines out to the fragged subs.
I got the OS9 copy function working,but in BETA testing the feature, I noticed that when I copied a file, I could not delete this file from within MShell. Moving to another window and trying to delete it manually resulted in a "No permission - File Busy" error. The copy routine closes all files properly so I know th file isn't open, but I can close MShell and then delete the file. But if I just re-open MShell, and try to delete the file from within MShell, it still gives the error. I can not figure out why MShell will not dlete the file. The file attributes are set to be exactly like the original so that is not the problem. I can delete the original file so it's something to do with the copy process and the file permissions. When I figure this out, I'll be able to continue with the source control as this feature is what will make it possible to move files to and from the source archive.
*************************************************************************************
Bug Huntin'... With A Hammer! (08/21/2014)
I have been taking a break from MShell and the Source Control system due to some activity in my recording studio. I had a couple of friends that needed a demo CD for their band and my daughter also wanted to do some recording. So I decided to take a break from the Coco world and do one of the few things that I love more than working with the Coco... playing and recording music! As a matter of fact, it was music that got me started on the Coco in the fist place and music is what has driven me to work with computers all these years.
As luck would have it, at the tail end of my recording sessions, my main computer died. I was installing a new graphics card when something caused the motherboard to go. I had been seeing some slight problems with my system lately ever since I replaced my power supply a few months ago. I think when the old power supply went, it had weakened something on the motherboard and when I installed the new graphics card, the motherboard couldn't take the extra power demands and failed. I've had to move all my Coco emulators and such to a much slower computer in the house and I no longer have access to my real Cocos since I have no room in the house to set them up. So any progress I make for now cannot be tested on the Coco until I replace the motherboard in my main system. Hopefully that will be soon. So... since I can't record at the moment, I'm back to working on MShell and the Source Control system for a bit. But as soon as I get my main system back up, I'm back to recording for a while.
After hours of searching the MShell code, I finally found the bug that was causing the "delete" error. In rerouting some disk read routines, I had inadvertently commented out a "close" statement in the the "file descriptor" read routine. So any file I selected was left open therefore causing an "Error 253" anytime I tried to perform any action on that file such as deleting it. Now the OS9 file copy and delete seem to work flawlessly. Now that these routines are working, I should be able to continue with the "Source Control" system. I have yet to dig back into that code, so I'll be reporting the progress as soon as I start back to working on it. Since I'm writing CCSCS ("Color Computer Source Control System") from scratch, my hopes are to optimize the disk routines to be more efficient than they are in MShell then adapt them to the MShell system therefore reducing memory usage. With MShell's many options, memory is always needed so any optimization is always appreciated. After many attempts, I cannot seem to move MShell's disk routines out into fragged subs. This HAS to be done in order to expand MShell to include all the features that I want. I'm still looking for ways to move some of the global variables out into virtual memory to clear some local memory for more features. I only have 8k for global memory so anything I can move to virtual memory is a plus.
Another thing I want to introduce into MShell is an "Error Report" system. For now, most error messages are generated on the fly so most of the text is stored locally in string values. This is a very inefficient way to do it, but there's no room in the global variables for message tables. I hope to put this routine in the "Ms1Grf" (independent graphics handler) and therefore keep it out of the main 64k system. The error reports can then be called by their error numbers and a message displayed on the screen. MS1Grf already contains a custom "print" routine in which I "pipe" all graphics, text and menu drawing codes in which allows Ms1Grf to then display them on the screen. This method keeps all those routines out of the main system.
But for now... I'll be digging back into the Coco Source Control System and see if I can get that code up and running.
*************************************************************************************
Page updated
Google Sites
Report abuse