hmmmmm
rjo__
Posts: 2,114
I have been playing with the 11-27 release and I have run into something that I don't think should ever happen.
Playing with the simple NTSC example, I changed the code slightly sorry no permanent record of exactly what I did, but it was pretty simple.
I set the mode from $A<<20 to $F<<20. and then in the AUX loading section after all values were set, I setspa to #128 and pushed a value of #255 and reset SPA to #0
This displayed the vertical line that I thought should be there however, when I went back and tried to get rid of it by eliminating the code and re-compiling it wouldn't go away!!!
I then changed the reps to #256 to be sure I was overwriting the location in the AUX and eliminated my other code changes (except mode changes) and that didn't work either. I powered down everything
and when I powered back up the vertical line was still there.
I then downloaded a fresh simple NTSC and that seemed to fix it.
What?
Playing with the simple NTSC example, I changed the code slightly sorry no permanent record of exactly what I did, but it was pretty simple.
I set the mode from $A<<20 to $F<<20. and then in the AUX loading section after all values were set, I setspa to #128 and pushed a value of #255 and reset SPA to #0
This displayed the vertical line that I thought should be there however, when I went back and tried to get rid of it by eliminating the code and re-compiling it wouldn't go away!!!
I then changed the reps to #256 to be sure I was overwriting the location in the AUX and eliminated my other code changes (except mode changes) and that didn't work either. I powered down everything
and when I powered back up the vertical line was still there.
I then downloaded a fresh simple NTSC and that seemed to fix it.
What?
Comments
I seemed to have eliminated a line in the reps loop. Sorry:)
Hmmmmm.....
I actually thought about that before I posted it. I thought I had a corrupted file that wasn't being recompiled:)
Thou shalt never hack on the original download of a file. Make a copy. Write protect that sucker so that your absent minded self can't mess with it whilst you are not paying attention. Always be able to get back to a working state. In fact use a source code management system. Use git.
Amen.
If you don't have a SMS, compress archives work great. If you are on windows, just right click and use the "compressed folder" option, and it will number them as copies, (1), (2), etc... On Linux, tar and friends work great and you can just specify numbered output files.
My own personal practice, sans an SMS system, is to number files as I work with them.
Assuming original download.
Archive it. Done.
Open files, build, attempt to run, whatever. Now you plan on changes. You can either clone the whole thing with the ideas above, or here is my personal practice for handling non SMS managed works in progress. It looks hard, but it turns out to be really simple after a time or two.
First read through the code you've got and parse the dependencies. Say it looks like this:
top.spin
--video.spin
----fonts.spin
--math.spin
If you are about to touch one, save as 01_filename.ext Do this before you do anything, so that your existing code state is preserved. This is about the only important habit here. Save as and number BEFORE edits. This is necessary for everything but the Prop Tool, which allows you to edit and build and run from RAM, meaning you can touch then save with a number after you edit and be safe with that one.
All other tools will write out the files as you build things, meaning you have to save and number before you edit things!
So you want to touch video.spin, and it gets saved as 01_video.spin. Now you know you need to touch top.spin too, because it calls video.spin. Save as 01_top.spin, and while you are there, edit the call to video.spin to reflect the new number 01_video.spin.
Now that folder contains two trees, both still buildable!
top.spin
01_top.spin
--video.spin
--01_video.spin
----fonts.spin
--math.spin
Before you make your edits, build it and verify the 01_ branch builds just like the original one does. If it doesn't, fix it right then.
Now you can make your edits. Again, this seems like a bit of a hassle, and it is and this hassle is why people will use SMS systems. But, once you've done it a time or two, it gets really easy and fast.
So then, you build and run 01_ and you find fonts and math need to be touched. This will form your 02_ branch, and that requires you make a decision.
The way I do it is to simply increment the number on any file. So a touch to fonts right now would be 01_fonts.spin, which would require touching 01_video.spin, so that becomes 02_video.spin. Math becomes 01_math.spin, and the top level gets touched again, which makes it 02_top.spin, and that looks like this:
top.spin
01_top.spin
02_top.spin
--video.spin
--01_video.spin
--02_video.spin
----fonts.spin
----01_fonts.spin
--math.spin
--01_math.spin
Now you've got the original, buildable by opening top.spin, the first revision 01_top.spin, and the current revision 02_top.spin. When you do this, you edit calls or includes to the other files right at the moment you save off a new numbered revision.
Or...
If you want to have your various iterations all numbered the same, you simply use the same number throughout! Meaning, you would label all files 02_ regardless of how often they have been touched, and that looks like this:
top.spin
01_top.spin
02_top.spin
--video.spin
--01_video.spin
--02_video.spin
----fonts.spin
----02_fonts.spin
--math.spin
--02_math.spin
The trade-off is ease of reading which file goes to which branch as opposed to having the files only change when needed. Let's say you send that code to somebody, and then you make edits in the future. They come to you with a numbered file. And you are a few branches ahead. If you number them all the same for ease of reading, you won't know whether or not a given numbered file is the same, and you have to compare. If you only number them when you change them, you know what has changed over time and can know which branches it's valid for...
Anyway, that's how I do it. Every so often, I archive the whole folder just in case. Otherwise, I just keep the whole mess numbered in the folder and I can build any branch at any time, keeping code states over time. It has saved my Smile quite a few times, and I've also been able to go back and explore design / code ideas too. I do something on Tuesday that should have been awesome, but really wasn't. Go back to last week, look at the other design choice, save off a new version and then combine the two, etc...
If you can get into the habit of doing this, you can work through bigger, more complex things and keep your states over time.
...or use git.
I think it's easier to read the git documentation than that scheme!
It's actually quite simple. All of it is iterative. One simple process handles everything, and the only requirement is to parse your code tree the first time to understand where the dependencies are called out. Tag those, and from then on, it takes a small amount of time to keep everything sane. I do it without thinking now. Frankly, that parsing needs to be done anyway, if you want to understand the code body you are working with.
And that process is:
Before edit, number file, work up the tree and number all parent files, editing their references to child files, done. That's it.
Now, if you have Chip's really cool editor tool, you can open up a set of files, make changes, and if you want to keep them, save as doing the same thing. Much faster and easier on iterations. This is why I like "build from RAM" as an option, which appears nowhere else.
...of course, I've been in and around managed data environments for MCAD since the mid 90's. This stuff comes second nature to me. However, I have taught a few people how to do this and they didn't have trouble, nor did it take them long. Andre' Lamonthe actually details a similar thing in his HYDRA book, for what that's worth. I'm not the only one to have gone down this simple road. (and it is simple in concept)
I really like mercurial as used by the PropGCC team. That system is awesome, and when I get setup for real on P2, I'll likely setup to use an online repository featuring that one. It's most closely aligned to the managed data systems I've used for years, and it's technical features make it worth the overall hassle.
Generally, I don't like a little bit of management. Either do it old school as I've shown, or use a system that rocks hard.
In any case, the hard part is getting into a version mindset. Frankly, that is harder for most people than the actual implementation of it is, even done manually.
You can send me a file I've authored with that system from 10 years ago, and I can tell you where it came from, what it's dependencies are and whether or not it can work with any version of anything I've put out here too. The cool part is when I've updated things and want to know whether or not a new video driver works with an older code body, for example. I can drop that file in, rename the original to xx_filename.ext.original, build, test, and answer that question in minutes.
With SMS systems, we get files and we need to understand metadata to make sense of them, and that metadata is often contained in other files we need to track. It's often not really possible to just exchange a file, without considering that other stuff. This file named X from code body Y, also used in code body Z, A, B, is what version? So then we compare things, build binaries, use checksums include stuff in the comments, README, etc...
Doing what I did above renders all of that moot. The name of the file contains the data you need to resolve those things with a simple search. And it even handles cases where multiple copies of things have been made. Merging them can be done with mere filename scripts and or copy / move operations. In my case, I've had code on USB keys, hard drive, multiple computers, whatever. Now I made the mess just working portable, and it's my fault, but it was not hard to gather it all up, sort through the names and recover one code body with it's revision history intact from day one with no real issues too.
It does require files be treated as atomic. If that can't happen, people definitely need SMS, and I recommend mercurial because of it's "change set" technical concept. Excellent. The little bit of time I've spent with PropGCC and that SMS was lean, mean, awesome. Highly recommended. (Great choice Jazzed) But any SMS will do, it's just trade-offs.
You get a lot for learning that process, and once it's learned, it works on ANYTHING. Not just source code. CAD files, various Office documents, basically anything that has dependencies on anything else. And your mind is ready for understanding an SMS, no matter what it does too. One stop shopping
So it's a way of working on filesystems more than anything else. Worth knowing, whether or not one uses SMS. Worth it, because there are a lot of dependent file type things that don't work with SMS, etc... For me, that ends up being graphics, media, and other messy tasks that have dependencies. I'll use the same process and it works there as it does for Prop code.
That working with others and or avoiding partial / multiple copies scenario is why people will use online repos, and they should too, particularly when there is more than one of them working on something.
It's a mindset more than anything else, and my experience has shown me that getting into that mindset is the hardest thing for people. How they get into it doesn't matter, only that they do. From there, it's just incremental work with payoffs all the way.