View previous topic :: View next topic |
Author |
Message |
rkumetz
Joined: 23 Jan 2007 Posts: 165 Location: Vermont
|
Posted: Sun May 31, 2020 10:10 pm Post subject: Output Files |
|
|
I just realized that 10+ years of writing Bascom code has created quite a mass of RPT, DBG and OBJ files.
Given that whenever one makes the decision to delete 100's of MB's of files it is wise to think carefully
before hitting the <ENTER> key I am wondering if anyone can think of a reason to keep these instead
of assuming I can recreate them by recompiling?
Better to have everyone snicker at my question than to be kicking myself later, right?
:shock:
(BASCOM-AVR version : 2.0.8.2 ) |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Jun 01, 2020 1:44 am Post subject: |
|
|
None of those are really directly useful without the source code, and IMHO you can delete them, assuming of course you still have the source !
I would even include the hex, eep and bin files in a real cleanup. Even though you can of course program a chip from them, working out which version they actually create can be tricky without a lot of documentation, and you may as well put that in the source code. On the other hand, they are quite small, so the disk space is probably barely worth recovering.
I used to archive them with the release, but in fact I found it was much better to archive the source in a version repository system. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
Posted: Mon Jun 01, 2020 12:11 pm Post subject: |
|
|
What's 100's of MB's these days.
I keep those files, why, because if you delete them you need them tomorrow
Very rare case you need a copy of hardware with Bascom code compiled in for example 1.11.4.0
You know this works perfect because the already existing hardware works flawless for 19 years. Flashing the existing hex file and you are done.
Recompiling with a newer version of Bascom gives always problems, due changes in the last years you can't compile it on first try. A example of this is that in the past variable and function names could have the same name without a problem, now it's not allowed any more.
If the software is then compiled you need to go trough all the testing again, that's including all the exceptions etcetera, that's time consuming. For most application we develop timing is critical and you have to recheck that also again.
That's why I keep all the Bascom version from day 1 and all the files used and generated.
Wasting 100MB's disk is is nothing compared the effort you maybe have to do in the future.
Just my 2 cent's. _________________ www.evertdekker.com Bascom code vault |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5914 Location: Holland
|
Posted: Tue Jun 02, 2020 9:48 am Post subject: |
|
|
when your project is finished and into production you should make a backup on CD and put the compiler (the setup and installation) the license key and the source and generated files.
this way you can make a quick change after 20 or 20 years. of course it requires testing but for a real simple change most of the tests can be skipped. (except when you launch a rocket)
new versions can behave different. for many reasons:
- there is a new function or statement and you used the same name(a rename can fix that)
- a bug is fixed but you depended on that bug.
- there is a new bug.
- variables you used are now system variables. renaming can fix that too.
but there are also reasons to use a new version. it is best if you plan that so there is no time pressure.
- there is support on the new version. old versions are not supported
- the new version has bugs fixed and maybe you was not even aware of the problem.
- the new version might have new functions that do part of the job simpler or better
in any case, these small files do not matter much. i would keep all files but most important :
- bin, rpt, cfg and obj and eep
from the obj you could recreate the bin and hex and you can convert bin to hex.
my first HD was 5 MB. Yes mega byte. but now there is a NAS with 4TB mirrored disks. so these few MB do not matter much. IMO it is best to safe the old setup files. and lib files if you made them yourself. _________________ Mark |
|
Back to top |
|
|
Paulvk
Joined: 28 Jul 2006 Posts: 1257 Location: SYDNEY
|
Posted: Tue Jun 02, 2020 10:43 am Post subject: |
|
|
Just look at how far we have come!
Software to fly to the moon back up!
|
|
Back to top |
|
|
six1
Joined: 27 Feb 2009 Posts: 553
|
Posted: Tue Jun 02, 2020 10:49 am Post subject: |
|
|
don't think so Paul...
Eagle and Apollo had a 4-Bit Calculation Unit and the Sourcecode will fit on a notice sheet of Paper _________________ For technical reasons, the signature is on the back of this message. |
|
Back to top |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
|
Back to top |
|
|
laborratte
Joined: 27 Jul 2005 Posts: 299 Location: Berlin
|
Posted: Tue Jun 02, 2020 3:36 pm Post subject: |
|
|
No, six1, this is real. the photo shows Margaret Hamilton with the source code, she and her team created for the Apollo mission.
https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer) |
|
Back to top |
|
|
six1
Joined: 27 Feb 2009 Posts: 553
|
Posted: Wed Jun 03, 2020 6:05 am Post subject: |
|
|
yes you are all right... readed the story again...
The Block I version used 4,100 ICs, each containing a single three-input NOR gate
The computer had 2048 words of erasable magnetic-core memory and 36 kilowords of read-only core rope memory
Impressive facts...
But as i understood, only parts of Source are loaded into "AGC" to compute _________________ For technical reasons, the signature is on the back of this message. |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Wed Jun 03, 2020 3:33 pm Post subject: Re: Output Files |
|
|
rkumetz wrote: | I am wondering if anyone can think of a reason to keep these instead
of assuming I can recreate them by recompiling? |
It may be a seldom occasion, but consider a source was compiled with an pretty old version of Bascom, ran perfectly for years, but needs reflashing.
Old Bascom version is picky to run on Winx900 and new version compiles slightly different.
You'll be happy to still have the old hex-file then.
Just compressed a lot I have here, zips from 32Meg to slightly 3Megs, thus ratio 10.
Quote: | to delete 100's of MB's |
translates then to a zip-file 10's of MB's big.
Which is nothing at all in times where USB sticks of up to two Terra-bytes are available. |
|
Back to top |
|
|
rkumetz
Joined: 23 Jan 2007 Posts: 165 Location: Vermont
|
Posted: Fri Jun 12, 2020 11:25 pm Post subject: |
|
|
AdrianJ wrote: | None of those are really directly useful without the source code, and IMHO you can delete them, assuming of course you still have the source !
I would even include the hex, eep and bin files in a real cleanup. Even though you can of course program a chip from them, working out which version they actually create can be tricky without a lot of documentation, and you may as well put that in the source code. On the other hand, they are quite small, so the disk space is probably barely worth recovering.
I used to archive them with the release, but in fact I found it was much better to archive the source in a version repository system. |
I do create archives and have a large fireproof waterproof box full of weekly backup DVDs as well as project specific archives.
I keep all of the hex files because if I need to recreate a problem it is much easier to just program a board than to have to recreate it from the source.
By doing that I also avoid making a mistake where I edit the source and forget to give it a new file name.
Thanks! |
|
Back to top |
|
|
|