Output Files

rkumetz · Joined: 23 Jan 2007 Posts: 165 Location: Vermont

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 )

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

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.

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

What's 100's of MB's these days.
I keep those files, why, because if you delete them you need them tomorrow Wink

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.

albertsm · Joined: 09 Apr 2004 Posts: 5920 Location: Holland

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.

Paulvk · Joined: 28 Jul 2006 Posts: 1257 Location: SYDNEY

Just look at how far we have come!
Software to fly to the moon back up!

six1 · Joined: 27 Feb 2009 Posts: 553

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 Very Happy

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

On one sheet of paper I doubt it will fit.

Source code can be find on github: https://github.com/chrislgarry/Apollo-11

laborratte · Joined: 27 Jul 2005 Posts: 299 Location: Berlin

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)

six1 · Joined: 27 Feb 2009 Posts: 553

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

MWS · Joined: 22 Aug 2009 Posts: 2262

rkumetz · Joined: 23 Jan 2007 Posts: 165 Location: Vermont