SimpleIDE_valet.exe (for lazy SimpleIDE users)
Phil Pilgrim (PhiPi)
Posts: 23,514
I've written a program to permit SimpleIDE running under Windows to do one-step compiles and loads. It starts SimpleIDE if it isn't already running, then creates a Go button:
When the Go button is clicked, it compiles whatever program is currently showing, and loads it into the Prop's RAM. When right-clicked, it just compiles the program without loading anything. When center-clicked (button under scroll wheel), it compiles and loads the program into EEPROM.
One caveat: Be aware that every time this button is used, the program is saved first. In SimpleIDE -- unlike in PropTool -- this also clears the Undo list.
Anyway, it's a stopgap for all of us lazy programmers, until Steve has a chance to make SimpleIDE more PropTool-like.
Enjoy!
-Phil
When the Go button is clicked, it compiles whatever program is currently showing, and loads it into the Prop's RAM. When right-clicked, it just compiles the program without loading anything. When center-clicked (button under scroll wheel), it compiles and loads the program into EEPROM.
One caveat: Be aware that every time this button is used, the program is saved first. In SimpleIDE -- unlike in PropTool -- this also clears the Undo list.
Anyway, it's a stopgap for all of us lazy programmers, until Steve has a chance to make SimpleIDE more PropTool-like.
Enjoy!
-Phil
Comments
-Phil
Myself I was not familiar with the use of BSTC. One thing it does as I type in code such as "pst.dec(a)" when I get to the "." it stops letting me input code and it brings up a selection box with a selection of a "." or one of the methods of pst to select causing me to have to hit an extra Enter or choose a method from the list to continue inputing code. Is there a way to turn off that feature?
I have no idea. Steve (jazzed) is the person to address with that query.
-Phil
I thought the blue arrow did single step compile/download/run?
No wait, that is in C in XMM mode to an SD card.
Hmm, if the blue arrow does single step compile/download/run in C, would it not be a good idea to have the same behaviour for Spin? ie a bit of internal code - "if compiler = spin, put PhiPi's Go button code behind the blue arrow"
Tricky. Spin will always be compiling to ram or eeprom, but unless you are writing tiny programs in C, C is more likely to be downloading to sd card or flash (or a big eeprom). So - what does the blue button do. The most common thing you are likely to want to do for that compiler? Or do you get the blue button to do what you set it to do in a drop down menu? Or is it a function of what memory model you are using? Or do you give the user full control in a setup menu?
I'll modify the program to look there, too.
-Phil
Don't confuse "one-step" with "single-step" -- they're two different things entirely. Also, I have no idea what effect my program has with C sources. I don't do C. Sorry.
-Phil
Thanks for going this extra mile however you did it - some perl thing guessing by the program size.
SimpleIDE.exe is usually installed in C:\Program Files\SimpleIDE\bin or C:\Program Files (x86)\SimpleIDE\bin.
It could be installed where ever the user wants it though.
DR_A,
The blue play button and others take the function hint from the board type - it's in the user guide. Spin ignores the board type.
I'll make the object-dot function optional. It's extra work to make optional (disabled by default), but it's worth having for some of us.
1. C:\Program Files\SimpleIDE\bin or C:\Program Files (x86)\SimpleIDE\bin.
2. The directory where SimpleIDE_valet.exe is installed.
So, if you don't have SimpleIDE installed in its default directory, just move the valet program to the bin directory where SimpleIDE is installed.
I've also improved the heuristics used to locate the SimpleIDE window once it's running. If the Go[/b[ button gets attached to the wrong window, let me know, and I'll take another stab at it. Also, if the valet program continues to run as a zombie process when SimpleIDE exits, I'll need to know that, too, along with an idea of what other windows are open. What makes this somewhat challenging is that the window name for SimpleIDE can be just "SimpleIDE" or "SimpleIDE" with other text following. Unfortunately, browser tabs can have the same window name if the title of the page that's open starts with "SimpleIDE".
-Phil
I'm not sure how you brilliant programer's do it but I thank you. If jazzed can make the object dot optional SimpleIDE is comming closer to Prop tool use.
As far as where the Go button showed up on my screen I attached a pix.
-Phil
I, personally, do not like the feature of compiler unsaved code. I always save all my source before compiling/running. However, I can see how some people might have gotten used to the feature (however, unsafe I think it is), so if it's really needed, then I could probably work with Steve to make it happen when using the spin.exe compiler.
Roy
The programs that I've written to pre-process Spin files before compilation and loading use the temp file method. It's really not that difficult. I just gather up the Top Level file and all the files in the object tree, save them to a temp directory, and invoke Propellent on the Top Level in the temp directory, after which the temp files are deleted.
Whatever method is chosen, there has to be a way to "drop anchor" on some previous version of an edited file for restoration when it becomes necessary. UltraEdit creates a .bak file upon a Load operation and autosaves the file before execution. That works for me when I'm doing Perl programming. The other nice thing about both UltraEdit and PropTool is that the Undo buffer is not cleared upon a Save operation. If you Undo from the Saved state, the "dirty bit" gets set again. This I feel is a necessary feature of any editor.
SimpleIDE, so far, lacks either of these safety features. When you compile, you have to Save, which clears the Undo buffer, and there was no automatic backup to revert to.
-Phil
-Phil
I do this because I'm a lazy programmer.....ok, basically a lazy person. I really like simple stuff.
I need to try this out Phil, thanks!
I agree with you that a save should not kill the undo buffer. That seems like a bizarre thing to do to me. The only thing that should wipe the undo buffer for a file is if you close it.
The thing that I do not like or think is safe, is compiling from in memory/edit tab versions of files like PropTool does. I think compiling should always be using the on disk versions of the files, and it should save files with changes before compiling.
You would have loved VMS. Every time you saved a file it would save a new copy with an increasing version number. Open the file and you get the latest version but you could also specify the version number and get back to a previous state.
Sometimes I wish Linux would do that.
I have seen many editors that empty the undo buffer when you save. It's really annoying.
VMS had another feature.. the TPU editor, which would save every keystroke and every action you did to a file. So you could later go back and edit your keystroke history file, then play it out on the original file and create a new, better version than what you did when you manually edited the original. This was actually feasible, it worked, and it was used in practice. And of course you could program the editor itself to look like whatever you wanted.
-Tor