Like just about everything else "warm fuzzy" = save, super easy, built in, default workflow, muscle memory. It's no different from an afternoon writing in Microsoft Word, or Powerpoint, and failing to save.
Most people do that once, maybe twice, then it's over.
What actually happens, is people do some work, like it, save that state, continue, maybe don't like it, revert, or maybe are not sure, so they save as, continue...
Have you ever lost your work because after an afternoon of testing you forgot to save your file?
.. or there was a power cut...., or windows decided to force a restart.... or the Class bell rang, and the stampede for the door occurred...
LOTS of reasons to not fool about with volatile memory, and very few reasons to actually need it.
More than enough ways for failures already lurk, without crafting new ones !
Many company flows expect/require that a batch build, gives the identical output every time. No context or order funnies lurking...
Frankly, being on laptops these days, very little of that kind of thing actually happens. (And Microsoft finally backed off the update mess. Computers don't just restart, and if they do, the user did something. So don't do that. And when they did fix that, I went ahead and setup a Win 10 machine. So far, it's pretty great. I'm happy as I was with 7, which is what my PropTool computer still runs for now.)
This isn't about companies. It's all about individual developers, perhaps small teams working on things. When one is rapid testing, learning, build from RAM is a killer workflow.
Make no mistake, build from disk is the pro way. I won't argue that. However, when one isn't a pro... Like I said, it's nice to have options.
It's the little stuff like this, how SPIN works, PropTool, etc... that made for a very compelling package. It is very different in some basic ways, and those matter to people. That is precisely why many who used the tools want to continue, myself included.
The little notebook holding PropTool, and some other goodies, has basically performed the same way for a really long time. All the code works, and it's robust. Love that, would not give it up very easy. IMHO, it's "finished" Better can be done. Has. If I need that, great! Really haven't, but for a time or two.
And that thing is some crappy Intel Atom, 1GB RAM, Win 7 Starter, or MATE Linux. It's juuuuuust enough to develop for the Prop very comfortably. It has more trouble loading larger web pages, and handling images than it ever does building P1 programs. I modified the batteries from the shipped default. It runs for basically a day. Weighs nothing, tiny.
If you are working on a laptop, netbook, tablet, or phone, power loss is a non issue, solved problem. Other things could happen. In practice, they basically don't. That's no joke.
Besides, this also isn't about changing 100 lines, adding 50, kinds of things. One could just save on a given investment like that.
No, this is about quick testing, change a value, conditional, edit some data, check, look good? Great, save, continue to build. Looks bad? Either revert, or modify, test, repeat. A really good use case is firing up a demo someone made. You can just poke at it to get a feel before jumping into doing something more involved. The other use case, I find compelling, is just picking through someone else's code. Poking around with no worries is a luxury, and super lean. Nothing really has to change, unless one is good and ready for that to actually happen, and there is no real planning involved, nor needed either.
These SSD devices have added one other nice change, and that is rapid, no moving parts, hibernate. I've set all my machines to do that on lid close, and I no longer have desktop machines at all. I can't tell you when I had a power event happen last. It's been darn near a decade. If not more. So, that "rush on class bell" case is a doddle. Just close the lid, stuff it in your back pack, and go! When you land somewhere, open it up, and it's all gonna be there, easy peasy.
Advances in tech have made this kind of workflow far less of an issue than it once was. Even then, it was fine, and millions of people do it every day too. My point being, having this as an option makes some sense for more users than we would probably admit. It's a nice option, that's all. One I would love to see continued because I do make use of it consistently.
Should we get an on-chip environment fired up, it will pay off there too.
When it's there, I find it feels much more like interpreted systems are. Speed and lean operation are both on par, at least for small to modest code bodies. It's nice to just write a couple lines, run it, write a couple more, or different ones, run those. Like for toggling pins, bone head simple hardware tests, poking at a sensor...
To get better, we need a real interpreter, or Tachyon, and the good news there is we get a little bit of that right out of the gate on P2!
Not all state is a big deal. In fact, I would argue for smaller state change or just the state itself, inclusive type cases, it's leaner to work this way than it is build from storage.
No, this is about quick testing, change a value, conditional, edit some data, check, look good? Great, save, continue to build. Looks bad? Either revert, or modify, test, repeat. A really good use case is firing up a demo someone made. You can just poke at it to get a feel before jumping into doing something more involved. The other use case, I find compelling, is just picking through someone else's code. Poking around with no worries is a luxury, and super lean...
Yup, I often do exactly that too, using the undo-across-save feature in Notepad, and conditional compile is great too. Works a treat, and I have less risk exposure.
Conditional compile also archives, so I remember what tests I did 5 months later. Try that with your RAM hosted forks !!
You have more overhead. And that's just fine. You've made investments with specific ends in mind. Having options means we all get to do that, or not, depending on what those ends and specifics may be.
It's like having interrupts, come to think about it. You know, there is people want to use them?
o Compiling from memory: There's nothing magic to this, many programs can do similar things. What you do is simply to write to a temporary file, using the 'give me a temporary filename' system function of your OS, compile, then delete the temporary file. No need for a compiler 'library', just execute the command line compiler as per usual.
o Forgot to save the file: My Emacs editor, and most sane editors, never let me do that. a) If I try to exit the editor it will ask me about every buffer I haven't saved, and b) it auto-saves continously to its own temporary files, so if I just shut down the computer I'll get access to the 'non-saved' files the next time I try to edit that file. I haven't lost a single file because of not-saving-it accidents, not in the last twenty years at least. Not once. I'm absolutely baffled whenever I hear about someone losing files that way. What editor are they using?
Tor,
your solution doesn't work in many cases. Top file includes a file by name, that file is in a tab edited, your temp file is ignored in compile. Same for many files included by other files, all in tabs... edited or not.
Once a file is opened create a copy of it into a temp file and keep a record of the temp file names for each real file. When any other file makes a reference to another just look up the temp file name for it and use that instead.
Kind of messy and clunky I guess.
Better to just compile what is in the real file. Save then compile.
If anyone wants to go backwards that is what undo is for.
If your experiments are a bit big to manage/revert with undo use git.
Once a file is opened create a copy of it into a temp file and keep a record of the temp file names for each real file. When any other file makes a reference to another just look up the temp file name.
It wouldn't work with a standalone compiler though - so it wouldn't solve the problem Roy pointed out w.r.t. my suggestion. The standalone compiler wouldn't know about the table that the editor maintains.
But, instead of a temporary file, write the buffer(s) to a temporary directory, using their proper names.. then a compile would work. Unless the 'include' directives point to absolute paths.
It's all just messy. The way proptool does it is simple. My code supports that.
You can do whatever you want.
Also, part of the reason I didn't mention my editor/ide thing before is all this design by committee stuff that happens here with people demanding you do it their way. I intended to just make it and drop it on you all, and let you deal with it.
I'm not really planning on finishing it now, too many other editors being made. I just wanted something to use OpenSpin properly and by default.
I love PropTool. It's simple and does the job and I love the built in editor, compiler and downloader. I like the compile without saving as I have my own method to save versions. But PropToo is missing a terminal emulator. PST works, but it's not ideal.
I also like bst with its inbuilt editor, compiler, downloader and terminal emulator. The additional compiler features such as conditional compiles, dead code removal, and @@@ make it indispensable when required.
However, P2 code development caused me to operate differently. In P2 I edited in PropTool, saved (but left it open), re-read in pnut and compiled and downloaded.
This took me back to the past where I had to use a separate editor, etc. So this leads me to a different opinion of what I think the P2 scene should look like...
A separate cross platform full featured editor... my choice is NotePad++. Syntax highlighting can be done somewhat easily. It's not going to be a PropTool equivalent. But then again, syntax highlighting can be done a lot better IMHO.
That leaves us with OpenSpin2. If it gets the support that it didn't unfortunately get in P1, then all those features such as macros etc that we've been wanting for the past 10 years might just get done.
So I guess I am leaning on the separate programs and tie them together by command passing or a batch file.
I think I have DAT sections drawing about right now...
Just noticed that things like "<<" get a different highlight, but going to ignore that for now...
Getting hard to tell between this and PropTool now...
I fixed the accelerator for redo also.
I think I have DAT sections drawing about right now...
Just noticed that things like "<<" get a different highlight, but going to ignore that for now...
Getting hard to tell between this and PropTool now...
I fixed the accelerator for redo also.
Whole reason I'm doing this is the get back the Prop Tool default coloring...
I've been using Prop Tool for many years now and somehow feel more comfortable with the colors.
I think it may actually help me remember how to code for Propeller...
Comments
Yup. Same.
Like just about everything else "warm fuzzy" = save, super easy, built in, default workflow, muscle memory. It's no different from an afternoon writing in Microsoft Word, or Powerpoint, and failing to save.
Most people do that once, maybe twice, then it's over.
What actually happens, is people do some work, like it, save that state, continue, maybe don't like it, revert, or maybe are not sure, so they save as, continue...
LOTS of reasons to not fool about with volatile memory, and very few reasons to actually need it.
More than enough ways for failures already lurk, without crafting new ones !
Many company flows expect/require that a batch build, gives the identical output every time. No context or order funnies lurking...
Frankly, being on laptops these days, very little of that kind of thing actually happens. (And Microsoft finally backed off the update mess. Computers don't just restart, and if they do, the user did something. So don't do that. And when they did fix that, I went ahead and setup a Win 10 machine. So far, it's pretty great. I'm happy as I was with 7, which is what my PropTool computer still runs for now.)
This isn't about companies. It's all about individual developers, perhaps small teams working on things. When one is rapid testing, learning, build from RAM is a killer workflow.
Make no mistake, build from disk is the pro way. I won't argue that. However, when one isn't a pro...
It's the little stuff like this, how SPIN works, PropTool, etc... that made for a very compelling package. It is very different in some basic ways, and those matter to people. That is precisely why many who used the tools want to continue, myself included.
The little notebook holding PropTool, and some other goodies, has basically performed the same way for a really long time. All the code works, and it's robust. Love that, would not give it up very easy. IMHO, it's "finished" Better can be done. Has. If I need that, great! Really haven't, but for a time or two.
And that thing is some crappy Intel Atom, 1GB RAM, Win 7 Starter, or MATE Linux. It's juuuuuust enough to develop for the Prop very comfortably. It has more trouble loading larger web pages, and handling images than it ever does building P1 programs. I modified the batteries from the shipped default. It runs for basically a day. Weighs nothing, tiny.
If you are working on a laptop, netbook, tablet, or phone, power loss is a non issue, solved problem. Other things could happen. In practice, they basically don't. That's no joke.
Besides, this also isn't about changing 100 lines, adding 50, kinds of things. One could just save on a given investment like that.
No, this is about quick testing, change a value, conditional, edit some data, check, look good? Great, save, continue to build. Looks bad? Either revert, or modify, test, repeat. A really good use case is firing up a demo someone made. You can just poke at it to get a feel before jumping into doing something more involved. The other use case, I find compelling, is just picking through someone else's code. Poking around with no worries is a luxury, and super lean. Nothing really has to change, unless one is good and ready for that to actually happen, and there is no real planning involved, nor needed either.
These SSD devices have added one other nice change, and that is rapid, no moving parts, hibernate. I've set all my machines to do that on lid close, and I no longer have desktop machines at all. I can't tell you when I had a power event happen last. It's been darn near a decade. If not more. So, that "rush on class bell" case is a doddle. Just close the lid, stuff it in your back pack, and go! When you land somewhere, open it up, and it's all gonna be there, easy peasy.
Advances in tech have made this kind of workflow far less of an issue than it once was. Even then, it was fine, and millions of people do it every day too. My point being, having this as an option makes some sense for more users than we would probably admit. It's a nice option, that's all. One I would love to see continued because I do make use of it consistently.
Should we get an on-chip environment fired up, it will pay off there too.
When it's there, I find it feels much more like interpreted systems are. Speed and lean operation are both on par, at least for small to modest code bodies. It's nice to just write a couple lines, run it, write a couple more, or different ones, run those. Like for toggling pins, bone head simple hardware tests, poking at a sensor...
To get better, we need a real interpreter, or Tachyon, and the good news there is we get a little bit of that right out of the gate on P2!
Not all state is a big deal. In fact, I would argue for smaller state change or just the state itself, inclusive type cases, it's leaner to work this way than it is build from storage.
Yup, I often do exactly that too, using the undo-across-save feature in Notepad, and conditional compile is great too. Works a treat, and I have less risk exposure.
Conditional compile also archives, so I remember what tests I did 5 months later. Try that with your RAM hosted forks !!
It's like having interrupts, come to think about it. You know, there is people want to use them?
Well, the beauty is that you can save your file as usual, it is in a different directory, but while compiling the file in the tab comes first.
Mike
o Forgot to save the file: My Emacs editor, and most sane editors, never let me do that. a) If I try to exit the editor it will ask me about every buffer I haven't saved, and b) it auto-saves continously to its own temporary files, so if I just shut down the computer I'll get access to the 'non-saved' files the next time I try to edit that file. I haven't lost a single file because of not-saving-it accidents, not in the last twenty years at least. Not once. I'm absolutely baffled whenever I hear about someone losing files that way. What editor are they using?
your solution doesn't work in many cases. Top file includes a file by name, that file is in a tab edited, your temp file is ignored in compile. Same for many files included by other files, all in tabs... edited or not.
Once a file is opened create a copy of it into a temp file and keep a record of the temp file names for each real file. When any other file makes a reference to another just look up the temp file name for it and use that instead.
Kind of messy and clunky I guess.
Better to just compile what is in the real file. Save then compile.
If anyone wants to go backwards that is what undo is for.
If your experiments are a bit big to manage/revert with undo use git.
It wouldn't work with a standalone compiler though - so it wouldn't solve the problem Roy pointed out w.r.t. my suggestion. The standalone compiler wouldn't know about the table that the editor maintains.
But, instead of a temporary file, write the buffer(s) to a temporary directory, using their proper names.. then a compile would work. Unless the 'include' directives point to absolute paths.
You can do whatever you want.
Also, part of the reason I didn't mention my editor/ide thing before is all this design by committee stuff that happens here with people demanding you do it their way. I intended to just make it and drop it on you all, and let you deal with it.
I'm not really planning on finishing it now, too many other editors being made. I just wanted something to use OpenSpin properly and by default.
Maybe I should get back to that completely in browser IDE msrobots and I were putting together some time ago...
I love PropTool. It's simple and does the job and I love the built in editor, compiler and downloader. I like the compile without saving as I have my own method to save versions. But PropToo is missing a terminal emulator. PST works, but it's not ideal.
I also like bst with its inbuilt editor, compiler, downloader and terminal emulator. The additional compiler features such as conditional compiles, dead code removal, and @@@ make it indispensable when required.
However, P2 code development caused me to operate differently. In P2 I edited in PropTool, saved (but left it open), re-read in pnut and compiled and downloaded.
This took me back to the past where I had to use a separate editor, etc. So this leads me to a different opinion of what I think the P2 scene should look like...
A separate cross platform full featured editor... my choice is NotePad++. Syntax highlighting can be done somewhat easily. It's not going to be a PropTool equivalent. But then again, syntax highlighting can be done a lot better IMHO.
That leaves us with OpenSpin2. If it gets the support that it didn't unfortunately get in P1, then all those features such as macros etc that we've been wanting for the past 10 years might just get done.
So I guess I am leaning on the separate programs and tie them together by command passing or a batch file.
Notepad++ is anything but cross platform. It's written to the legacy Win32 API.
I think this is potentially where things get really interesting. Keen to see what Chip has in mind for those second VGA ports on the P123 boards.
Good times ahead, IMHO
Oh! I thought it was cross platform and open source.
Just noticed that things like "<<" get a different highlight, but going to ignore that for now...
Getting hard to tell between this and PropTool now...
I fixed the accelerator for redo also.
Looking good!
Yeah, where are you headed? LOL.
Does your colorizer allow users to pick the colors/bold/etc. for each catagory like PropTool, or are you just using the defaults fixed?
I've been using Prop Tool for many years now and somehow feel more comfortable with the colors.
I think it may actually help me remember how to code for Propeller...