Managing spin library files
David B
Posts: 592
How to you manage your spin library files?
On my home computer, I've got a project folder and a separate library folder.
The project folder contains a few dozen "top" spin program files and the library folder contains several dozen library spin files. Each "top" spin file in the program folder includes one or more of the library files.
The problem comes when I need to modify an existing library file for a new project, because changes to existing library code sometimes breaks functionality for other projects.
Another problem comes when I've developed a project on a separate computer, then want to merge it with my main computer and get a modified library file conflict.
Has anyone found a need to use something like a more Linux-like convention of having separate versions of library spin files, where each filename includes a version number?
On my home computer, I've got a project folder and a separate library folder.
The project folder contains a few dozen "top" spin program files and the library folder contains several dozen library spin files. Each "top" spin file in the program folder includes one or more of the library files.
The problem comes when I need to modify an existing library file for a new project, because changes to existing library code sometimes breaks functionality for other projects.
Another problem comes when I've developed a project on a separate computer, then want to merge it with my main computer and get a modified library file conflict.
Has anyone found a need to use something like a more Linux-like convention of having separate versions of library spin files, where each filename includes a version number?
Comments
Under a master Object directory, I have a separate directory that represents each year.
Under each year directory, I have corresponding months
Within each month I have a descriptive project name where the spin file(s) live.
If I'm working on a project that requires a change to a spin file in the master library (<- located in the IDE install path), then that file that required a change gets copied and moved into the current Month directory and now becomes isolated and unique as to not interfere with existing or future projects.
My solution is to keep all the local files in an folder. Also, I use BST instead of the propeller tool. I try to call all the 'main' programs something with the word 'main' so I can remember which is the main program.
Then when I want to open a program, I open BST, point it to the correct folder, then open the 'main' program.
And for good measure I do a zip from time to time, so if a file does get corrupted I have a backup.
Please don't do that.
Masochists who want full up object oriented madness on their Propellers can use C++ and Zog:)
Besides I'm not sure that using inheritance to solve this "multiple versions of tweaked objects" is the correct way to go.
Anyone who is having serious problems with a mass of almost the same objects that tweaked to fit different projects at different times should probably consider getting into using a source code version control system.
Using a tool such as "git" one can maintain a "tree" of versions all emanating from the same original version. Each "branch" of this tree can be labeled with some name that lets you know when and or what it was created for.
As a long-time Java programmer, I'd love to see inheritance in Spin, so that I could define a new object as "extends foobar", which would let me add a few new methods to the existing "foobar" object without having to duplicate all of the existing methods, but I can live without it. Living without search paths would be far less acceptable - thanks Brad for BST!!!
While not exactly inheritance, you can get inclusion of the object by using "has-a" relationship and providing the calls to the methods you want keep exposed. You don't have to duplicate the methods already included, but you still have to provide the entry points for them (as there's no virtual method resolution in Spin).
Probably right. But Spin is much more human-friendly than C++ so a few tweaks would be better than once again subjecting myself to that madness. I built a prototype OODB once and swore I would never torture myself with C++ again.
Of course, I was light-years away from the hardware.
Read all about it:
http://forums.parallaxinc.com/forums/default.aspx?f=25&m=298620
and Parallax's thumbs up:
http://www.parallax.com/ProductInfo/Microcontrollers/PropellerGeneralInformation/PropellerDownloads/BSTforPropeller/tabid/828/Default.aspx
Jim
Get it from here: http://www.fnarfbargle.com/bst.html
-Phil
I guess Parallax needs to update the link on that page.
(http://www.parallax.com/ProductInfo/Microcontrollers/PropellerGeneralInformation/PropellerDownloads/BSTforPropeller/tabid/828/Default.aspx)
Jim
I'm also just getting started transitioning to using bst on Ubuntu and in the process, trying to come up with a better way of managing all the files - top files, included library files and PC-based GUI source files, for those projects that connect to a remote GUI.
I used to keep all my main "top" files in one "top_spin_file" folder but it started to get cumbersome when different projects also started to get their own Delphi projects with its dozen or so files.
So in Ubuntu I'm starting to dedicate a folder to each project, where each folder will contain a single spin "top" main file, and the folder will also contain the Lazarus (Delphi-like GUI builder) sources if the project uses a separate GUI on the PC.
I'd like to keep a common library folder for all the spin files that drive hardware devices like ADCs, the breadboard LCD, RS232 serial. Managing changes to those shared files is what my main question was about.
I don't think version control would solve my problem because a spin library file still could be checked out, have methods changed without changing the file name, then checked back in, breaking other projects that had included that file.
Here's an example. For one project, I modified Chip's FullDuplexSerial to be able to transmit and receive at two different baud rates so a project could use that library to receive from a 4800 baud GPS and display to a 9600 baud LCD.
But that required an additional baudrate argument in its start method, so any other project already written to use FullDuplexSerial would then be broken. But my modified FullDuplexSerial is still just as functional as the original, and so it really should be used instead of the original in new work, rather than making a separate version.
I'd like to be able to not break earlier projects but at the same time, make it clear that a particular library file should be considered to be the most current and should be used by new projects.
Maybe a simple variation of the Linux library file version numbering may be good enough, like -
FullDuplexSerial.01.spin
FullDuplexSerial.02.spin
and I was curious if anyone else had already starting using any alternate spin library naming convention like that.
No way. In a version control system like "git" you can have one line of development, from the first ever version to the latest. Along the way you can add "tags" to versions. Tags basically give you a label for a meaning full, significant, version that you would like to be able to recall later if necessary.
In addition with tools like "git" you can split branches off from the main line work to meet special requirements or try out experimental changes. Again those branches can be developed through many versions and tagged when required.
Development can go on in many directions at the same time.
So for a given library object, you may have a different branch for each project that uses it with different tweeks. Name the branches to reflect the project name using it.
Putting all to together with appropriate working directories for each projects version of each library object means that all projects can always checkout exactly the variant/version of an object they need.
Of course all your top level objects will be in "git", or whatever as well.