Is it possible to use the GCBsoftware (SynWrite 6.22.2290) to hexflash without automatic saving to disk?
Normally I program by having a leading file with code and test all sorts of situation codes before I save again.
After some time I backup that file and move on with more changes.
Often I retrieve the previous backups to investigate the trials and errors.
So therefore I checked the PullDown menu, Options, Customize and couldn't find such setting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the past I used a (freeware) program called AutoVer. You create a watcher which then monitors a given folder (and or sub folders) backing all changes up to another folder. This keeps a track of all files which are marked with the time and date. These files can then be retrieved should any need happen.
As the name of the program this is all done automatically once set. The program can monitor multiple folders, isn't limited to any one file type and can be set to automatically start with Windows. It has saved my sanity more than once.
😄
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Its not possible to compile without saving because the compiler needs the file saved, i can recommend to use a subversion system like GIT to keep track of the code changes and go back and forth on them, that is one of the main purposes of those systems.
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GC Code keeps a copy of the timeline of changes. You can revert to a specific time - therefore you can easily restore previous version of the source program.
Last edit: Anobium 2023-01-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is easy to open a demo file, alter it then test it, to then realise you have saved the altered demo
file when it should have been saved under a different name and not in the demos folder.
Well I've done that many times, oops.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the past I've changed my original HDD to a SSD and april 2022 had to replace the SSD for failing most likely of exeeding the “Wear Level".
From then on I keep track and minimizing software writes to SSD drive for longer life span.
So, with every GCB Flash test to the chip I will degrade my SSD and with a Hex even further for making an extra hex-file too.
With softwares like GC-Code and AutoVer that will expand the problem by making more files thus extra writes to the SSD.
Stan: It is easy to open a demo file, alter it then test it, to then realise you have saved the altered demo
file when it should have been saved under a different name and not in the demos folder.
Well I've done that many times, oops.
Anobium: Me too. I have overwritten the Master Demos so many times!
I think that I made the most mess not knowing of the hexflash save :-)
I tried many GCB example files with editing ports and to the specific Arduino or Microchip I had plugged-in. But that can be reset by installing the GCB software again or by download the ever expanding online example files.
But in the end there still remains the "problem" we all have, and try to correct by alternative methods, of not wanting to save to disk by flashing a chip.
Is there really no way to alter the GC(B)software as a setting-option to NOT save to (SSD) disk?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Question to the experts: On the handling of the SSD when a block has been written to more than 3000 times - surely it would make the block as a 'bad block' as write a complete block somewhere else.
True / False ? explain please.
And, if the SSD is not full ( 100%). Then, what is the life cycle in relation to the % of the SSD used ?
Great Cow BASIC can write the outputs to a single filename. But, this will have no impact on the write count to the SDD. As the same number of write operations will happen.
A RAM drive? They still exist and are very clever. Write to the RAM drive then move the final file to SDD.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For arduino there's an old prog called XLoader that flashes gcb hex files.
I used a drive clone program, can't remember the name, to clone my HDD PC's to SDD.
It cloned a 1TB HDD to 250G SSD and a 512G HDD to 240G SSD 6 years ago and all is well. This pc says 94.3G left from 222G.
SDD drives spread the data around so it doesn't rewrite the same drive memory I think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SDD drives spread the data around so it doesn't rewrite the same drive memory I think
I think so but does that apply to editting the same (GCBfile) over and over again too?
A RAM drive? They still exist and are very clever. Write to the RAM drive then move the final file to SDD.
Great idea for a very fast separate drive and problem can be solved if GCBsoftware could have the option to only do (Hex)FlashSave to RAM drive and keep the CodeSave to SSD with the existing Save icon.
Then even a cheaper small sacrificial USBstick will do.
No more exidental overwrites.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was thinking you could implement a RAM drive to resolve this worry. But, the OS is creating and deleting many, many more temp files than GC BASIC.
I am meeting the CTO of HP today. I will ask him if he can advise on SDD risks. I have many SDD devices and I have never thought about this issue. I take regular backups and use SVN to protect projects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In USE.INI to use the system temp directory for compiler temp files. Options are "tempdir" or "instdir" or remove the option.
'workingdir = "tempdir"
So, if you set your system temp directory to an external USB drive - all temp file ( including the OS temp files) will be written to the USB drive. You would have to change the System Environment Variables tmp and temp. There may be risks to the OS making this change so please research first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a misconception, its true that every block on an SSD have a specific endurance time, but normally is much higher than 3000 cycles, the ssd firmware is designed to not write on the same block every time, instead it writes on fresh ones, just counting GCB files its imposible that you have enough life to save again and again gcb files and wear out an SSD, in this case a SSD will outlast you.
Even the OS will have a higher foot print on the wear than your saved files :-)
Also SSD's have over provisioning; in example, a labeled 1TB SSD in reality have more "hidden" space (some times 10% to 20%) as a spare in case you wear out some blocks or if you have a damaged ones.
You really need a very intensive disk IO to start to wear an ssd, like adding an SSD to a video surveillance role on an NVR, and even if you write the entire disk every week in this application you will need 57 years to wear out an ssd with 3000 cycles per block.
So better trow away your fears and enjoy your life.
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Angel Mier
Good to know, thanks for the reasurance of the SSD drive criteria.
But in the end there still remains the "problem" we all have, and try to correct by alternative methods, of not wanting to save to disk by flashing a chip.
No more exidental overwrites.
'workingdir = "tempdir"
So, if you set your system temp directory to an external USB drive - all temp file ( including the OS temp files) will be written to the USB drive. You would have to change the System Environment Variables tmp and temp. There may be risks to the OS making this change so please research first.
Could this be the solution also for GCB flash files written to a separate directory?
My project code file(s) will still be written to my project directory with the Save-icon?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The process of compilation requires the file to be written to a file store. So, if you used a USB drive or any form of drive the file will need to written so compilation processing can happen. The editor (want ever sort you are using) is not part of the compiler.
I think Timeline in GC Code is best, then AutoVer for SynWrite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the GCB-editor can't write to a different directory/drive for the Compiler to flash the gcb supported external chip than indeed Timeline, AutoVer and SynWrite are the only solutions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I loaded a gcb file then saved it in Videos folder. Flash hex created files in the Videos folder,
no device attached.
Where you save the file becomes the default save.
I'll try a usb ssd
Indeed, after every HexFlash 5 files will be created instead of what I thought just one *.gcb file.
To avoid saving every hexflash as seperate files for every trial with Timeline, AutoVer and SynWrite I've decided to manually copy a backup file every time I think some part of code should be saved.
Not a problem yet because now I'm just learning examples in my spare time.
Thanks for the help everyone.
Last edit: Haroen 2023-01-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haroen - I've decided to manually copy a backup file every time I think some part of code should be saved.
That's just what I do as well, by appending a copy file code.gcb.bak1, code.gcb.bak2... in the working folder & at session end I copy changed files to external drive in chronological backup folders.
Has saved my sanity on many occasions.
Slightly relevant...
When I compile a .gcb with SimulIDE it puts output files into a sub folder in the working folder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Useful advice if testing code - create sub folders for pic, arduino, lgt and let win save as file (1), file (2) etc.
I got too many files to find anything when I want it :(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use the Windows-Explorer method of selecting the file and holding the Right Mouse button and drag the file(with the cursor) to an empty spot in the same folder thus creating copies from Haroen.txt like:
Haroen - kopie.txt
Haroen - kopie (2).txt
Haroen - kopie (3).txt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just been hit by this problem and lost a day's work - an accidental compile does the damage ... overwritten source and then closing GCB does the damage and you don't get to find out until you open it the next time and by then you can't remember what you edited !
I've never seen a compiler that has this problem - even when managed carefully you end up with masses of files and it still becomes a versioning nightmare !
The given explanation is that the compiler needs to be passed source code that's stored on disk ... so why not save the source for compile as an "on-the-fly" temporary file that gets deleted after compiling. The IDE can track if changes have occurred and prompt the user prior to closing. That's how many other IDE / Compilers do it.
A great piece of work ... but this one has me trying to tear my hair out ... which is really difficult these days - baldness !
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About that any other compiler doesn't have this behavior:
I disagree on this one, “almost” every other dev environment that I have used (even top tier ones) behave in the same way; NetBeans, Jet Brains, RIDER, Visual Studio 2022, you name it.
I added the word “almost” because maybe someone that I don’t know could work different, but that will be the exception rather than the rule.
So, now what?
The best way around this is not changing the behavior; because one day you may hit the save button instead of compile, and you have again another data loss.
I don’t want to sound harsh; I wish the best for all of you out there, but I need to say that this can be fixed by changing the user workflow.
Seasoned programmers learn (the hard way) to use version control systems (GIT, SVN, etc.) not because they want to learn yet another tool (and sometimes complicated ones). But because this gives more control, versatility and ease of mind. These systems give you the option to have one stage (your current directory) where you can modify your code and do any weird things to it, like if you were on a playground and then if nothing goes as intended you can easily revert back to normal. Then you can commit new changes and add comments of your modifications. And, if in the future something goes south, you can revert to any point behind the culprit change.
For this to work, you need to make the habit to do the commits periodically, and this will become second nature with time.
I heavily suggest that everyone learn to use version control, and preferable GIT as this is the most widely used one and you even don’t need a server or anything, a git repository can be a simple folder on your computer. Remember that GCstudio have built in GIT integration (and a great one), so it is very user friendly to use (you don’t need to learn commands)
Angel
Last edit: Angel Mier 2024-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes ... kind of agree. In my past PDP / VAX days then there was no alternative to manually saving and then having to initiate a compile and link - usually involved several hours so it encouraged careful programming to avoid hours going by only to find a syntax error. Source control was good as the editor EDT automatically incremented a file's version name - just meant that you ended up with lots and lots of files !
Days moved on and I've been programming commercially in Delphi / Embarcadero ever since and that doesn't overwrite code !
,,, and I do consider myself to be a seasoned programmer having produced some fairly major works including a version of Scrabble, rendered in OpenGL 3D that sold commercially throughout Europe, Canada, South America and Australia - Letter Rack 3D, as well as other projects within TV broadcasting.
But yes, I totally agree, code will get lost whichever and whenever so no excuse for not adopting proper version control but I prefer those quick hacks when you want to quickly test something in the code and then forget that just one compile will lose the original.
Curiosity got the better of me and I looked at other languages and you're correct, many do overwrite original source files - but there are a lot of comments describing the resulting anguish when they too make the same oversight as mine and it seems quite a few compilers can throw a wobbly resulting in corrupted files.
So whatever - we all have experienced the same thing !
Last edit: Andrew Jameson 2024-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to use the GCBsoftware (SynWrite 6.22.2290) to hexflash without automatic saving to disk?
Normally I program by having a leading file with code and test all sorts of situation codes before I save again.
After some time I backup that file and move on with more changes.
Often I retrieve the previous backups to investigate the trials and errors.
So therefore I checked the PullDown menu, Options, Customize and couldn't find such setting.
In the past I used a (freeware) program called AutoVer. You create a watcher which then monitors a given folder (and or sub folders) backing all changes up to another folder. This keeps a track of all files which are marked with the time and date. These files can then be retrieved should any need happen.
As the name of the program this is all done automatically once set. The program can monitor multiple folders, isn't limited to any one file type and can be set to automatically start with Windows. It has saved my sanity more than once.
Its not possible to compile without saving because the compiler needs the file saved, i can recommend to use a subversion system like GIT to keep track of the code changes and go back and forth on them, that is one of the main purposes of those systems.
Angel
Using GC Code can really help with this.
GC Code keeps a copy of the timeline of changes. You can revert to a specific time - therefore you can easily restore previous version of the source program.
Last edit: Anobium 2023-01-09
It is easy to open a demo file, alter it then test it, to then realise you have saved the altered demo
file when it should have been saved under a different name and not in the demos folder.
Well I've done that many times, oops.
Me too. I have overwritten the Master Demos so many times!
I use SVN to roll back
But, now with Timeline in GC Code it is a lot easier to roll back to a previous build.
There is the criteria of HDD versus SSD with only 3000 write cycles.
In the past I've changed my original HDD to a SSD and april 2022 had to replace the SSD for failing most likely of exeeding the “Wear Level".
From then on I keep track and minimizing software writes to SSD drive for longer life span.
So, with every GCB Flash test to the chip I will degrade my SSD and with a Hex even further for making an extra hex-file too.
With softwares like GC-Code and AutoVer that will expand the problem by making more files thus extra writes to the SSD.
I think that I made the most mess not knowing of the hexflash save :-)
I tried many GCB example files with editing ports and to the specific Arduino or Microchip I had plugged-in. But that can be reset by installing the GCB software again or by download the ever expanding online example files.
But in the end there still remains the "problem" we all have, and try to correct by alternative methods, of not wanting to save to disk by flashing a chip.
Is there really no way to alter the GC(B)software as a setting-option to NOT save to (SSD) disk?
Question to the experts: On the handling of the SSD when a block has been written to more than 3000 times - surely it would make the block as a 'bad block' as write a complete block somewhere else.
True / False ? explain please.
And, if the SSD is not full ( 100%). Then, what is the life cycle in relation to the % of the SSD used ?
Great Cow BASIC can write the outputs to a single filename. But, this will have no impact on the write count to the SDD. As the same number of write operations will happen.
A RAM drive? They still exist and are very clever. Write to the RAM drive then move the final file to SDD.
For arduino there's an old prog called XLoader that flashes gcb hex files.
I used a drive clone program, can't remember the name, to clone my HDD PC's to SDD.
It cloned a 1TB HDD to 250G SSD and a 512G HDD to 240G SSD 6 years ago and all is well. This pc says 94.3G left from 222G.
SDD drives spread the data around so it doesn't rewrite the same drive memory I think.
I think so but does that apply to editting the same (GCBfile) over and over again too?
Great idea for a very fast separate drive and problem can be solved if GCBsoftware could have the option to only do (Hex)FlashSave to RAM drive and keep the CodeSave to SSD with the existing Save icon.
Then even a cheaper small sacrificial USBstick will do.
No more exidental overwrites.
I was thinking you could implement a RAM drive to resolve this worry. But, the OS is creating and deleting many, many more temp files than GC BASIC.
I am meeting the CTO of HP today. I will ask him if he can advise on SDD risks. I have many SDD devices and I have never thought about this issue. I take regular backups and use SVN to protect projects.
Then, I remember this... https://gcbasic.sourceforge.net/help/_development_guide_for_great_cow_basic_preferences_editor.html
Search for
workingdir.In USE.INI to use the system temp directory for compiler temp files. Options are "tempdir" or "instdir" or remove the option.
'workingdir = "tempdir"So, if you set your system temp directory to an external USB drive - all temp file ( including the OS temp files) will be written to the USB drive. You would have to change the System Environment Variables
tmpandtemp. There may be risks to the OS making this change so please research first.This is a misconception, its true that every block on an SSD have a specific endurance time, but normally is much higher than 3000 cycles, the ssd firmware is designed to not write on the same block every time, instead it writes on fresh ones, just counting GCB files its imposible that you have enough life to save again and again gcb files and wear out an SSD, in this case a SSD will outlast you.
Even the OS will have a higher foot print on the wear than your saved files :-)
Also SSD's have over provisioning; in example, a labeled 1TB SSD in reality have more "hidden" space (some times 10% to 20%) as a spare in case you wear out some blocks or if you have a damaged ones.
You really need a very intensive disk IO to start to wear an ssd, like adding an SSD to a video surveillance role on an NVR, and even if you write the entire disk every week in this application you will need 57 years to wear out an ssd with 3000 cycles per block.
So better trow away your fears and enjoy your life.
Angel
@Angel Mier
Good to know, thanks for the reasurance of the SSD drive criteria.
Could this be the solution also for GCB flash files written to a separate directory?
My project code file(s) will still be written to my project directory with the Save-icon?
The process of compilation requires the file to be written to a file store. So, if you used a USB drive or any form of drive the file will need to written so compilation processing can happen. The editor (want ever sort you are using) is not part of the compiler.
I think Timeline in GC Code is best, then AutoVer for SynWrite.
If the GCB-editor can't write to a different directory/drive for the Compiler to flash the gcb supported external chip than indeed Timeline, AutoVer and SynWrite are the only solutions.
I loaded a gcb file then saved it in Videos folder. Flash hex created files in the Videos folder,
no device attached.
Where you save the file becomes the default save.
I'll try a usb ssd
Last edit: stan cartwright 2023-01-11
Indeed, after every HexFlash 5 files will be created instead of what I thought just one *.gcb file.
To avoid saving every hexflash as seperate files for every trial with Timeline, AutoVer and SynWrite I've decided to manually copy a backup file every time I think some part of code should be saved.
Not a problem yet because now I'm just learning examples in my spare time.
Thanks for the help everyone.
Last edit: Haroen 2023-01-13
That's just what I do as well, by appending a copy file code.gcb.bak1, code.gcb.bak2... in the working folder & at session end I copy changed files to external drive in chronological backup folders.
Has saved my sanity on many occasions.
Slightly relevant...
When I compile a .gcb with SimulIDE it puts output files into a sub folder in the working folder.
Useful advice if testing code - create sub folders for pic, arduino, lgt and let win save as file (1), file (2) etc.
I got too many files to find anything when I want it :(
I use the Windows-Explorer method of selecting the file and holding the Right Mouse button and drag the file(with the cursor) to an empty spot in the same folder thus creating copies from Haroen.txt like:
Haroen - kopie.txt
Haroen - kopie (2).txt
Haroen - kopie (3).txt
Just been hit by this problem and lost a day's work - an accidental compile does the damage ... overwritten source and then closing GCB does the damage and you don't get to find out until you open it the next time and by then you can't remember what you edited !
I've never seen a compiler that has this problem - even when managed carefully you end up with masses of files and it still becomes a versioning nightmare !
The given explanation is that the compiler needs to be passed source code that's stored on disk ... so why not save the source for compile as an "on-the-fly" temporary file that gets deleted after compiling. The IDE can track if changes have occurred and prompt the user prior to closing. That's how many other IDE / Compilers do it.
A great piece of work ... but this one has me trying to tear my hair out ... which is really difficult these days - baldness !
Andrew
Hi Andrew, I’m sorry to hear about your data loss, remember that timeline function explained by Evan may help. https://sourceforge.net/p/gcbasic/discussion/579125/thread/5729d82474/?limit=25#4880
About that any other compiler doesn't have this behavior:
I disagree on this one, “almost” every other dev environment that I have used (even top tier ones) behave in the same way; NetBeans, Jet Brains, RIDER, Visual Studio 2022, you name it.
I added the word “almost” because maybe someone that I don’t know could work different, but that will be the exception rather than the rule.
So, now what?
The best way around this is not changing the behavior; because one day you may hit the save button instead of compile, and you have again another data loss.
I don’t want to sound harsh; I wish the best for all of you out there, but I need to say that this can be fixed by changing the user workflow.
Seasoned programmers learn (the hard way) to use version control systems (GIT, SVN, etc.) not because they want to learn yet another tool (and sometimes complicated ones). But because this gives more control, versatility and ease of mind. These systems give you the option to have one stage (your current directory) where you can modify your code and do any weird things to it, like if you were on a playground and then if nothing goes as intended you can easily revert back to normal. Then you can commit new changes and add comments of your modifications. And, if in the future something goes south, you can revert to any point behind the culprit change.
For this to work, you need to make the habit to do the commits periodically, and this will become second nature with time.
I heavily suggest that everyone learn to use version control, and preferable GIT as this is the most widely used one and you even don’t need a server or anything, a git repository can be a simple folder on your computer. Remember that GCstudio have built in GIT integration (and a great one), so it is very user friendly to use (you don’t need to learn commands)
Angel
Last edit: Angel Mier 2024-07-07
Also, very sorry to hear about this loss. I would follow Angel's advice. :-)
Yes ... kind of agree. In my past PDP / VAX days then there was no alternative to manually saving and then having to initiate a compile and link - usually involved several hours so it encouraged careful programming to avoid hours going by only to find a syntax error. Source control was good as the editor EDT automatically incremented a file's version name - just meant that you ended up with lots and lots of files !
Days moved on and I've been programming commercially in Delphi / Embarcadero ever since and that doesn't overwrite code !
,,, and I do consider myself to be a seasoned programmer having produced some fairly major works including a version of Scrabble, rendered in OpenGL 3D that sold commercially throughout Europe, Canada, South America and Australia - Letter Rack 3D, as well as other projects within TV broadcasting.
But yes, I totally agree, code will get lost whichever and whenever so no excuse for not adopting proper version control but I prefer those quick hacks when you want to quickly test something in the code and then forget that just one compile will lose the original.
Curiosity got the better of me and I looked at other languages and you're correct, many do overwrite original source files - but there are a lot of comments describing the resulting anguish when they too make the same oversight as mine and it seems quite a few compilers can throw a wobbly resulting in corrupted files.
So whatever - we all have experienced the same thing !
Last edit: Andrew Jameson 2024-07-07