I use BSTC at the moment due to its compression feature. Otherwise it can’t compile due to file too large. Different Loaders is cool too. FTDI, Silabs etc. all these can be linked with simple scripts to access command line tools. For example have a button that you can define for compile and a button to define for loader. Thats sort of what I have on my editor.
What do you mean by "compression feature"? OpenSpin can eliminate unused code I believe. I don't think any new project should use BSTC since it is completely unsupported and could stop working at any moment with no ability to resurrect it. OpenSpin is the way to go for new projects.
I said compression but that’s not what it’s called. Its the option(s) that make the code much smaller in BSTC. I link to BSTC from my editor. Very easy. I haven’t looked at Open spin but I need to do a comparison for size.
I said compression but that’s not what it’s called. Its the option(s) that make the code much smaller in BSTC. I link to BSTC from my editor. Very easy. I haven’t looked at Open spin but I need to do a comparison for size.
I suspect you're talking about the unused code elimination feature that is available in OpenSpin as well.
There are some projects that the Spin Tool can't handle, but BST can. This happens when there are many object references, but there are only a few unique objects that are used. The final image fits in 32KB, but for the Spin Tool it appears that the intermediate image is larger than 64KB before it can merge the duplicate objects. In the Spin Tool this will fail with an error that the binary is greater than 64K. The same code will work fine with BST. I don't know if this problem was fixed in OpenSpin, or whether it has the same issue as the Spin Tool.
T Chap,
OpenSpin's unused code elimination does more than BSTC's does, so in many cases the results are smaller. For example OpenSpin can remove an entire object if none of the methods are called (and still allows you to use CON stuff from the removed object since those are just compile time symbols).
Dave Hein,
Pretty sure OpenSpin can deal with that (as long as the end result fits). If also has an option to allow you to make eeprom files larger than 32k.
Ray,
The way I have setup the OpenSpin code, you could easily make it into a library or even DLL. Then you can link it into your editor and call it for compiles and make your editor work exactly like PropTool for compiling (even compiling from the code in the open editor tab without saving). I have an alternate "wrapper" locally that I did for my editor (that's unfinished and may never be) that I'd be fine with sharing with you if you want to integrate it into your editor.
Pity you are making it in such a way that it's windows only. You really should look into something that can at least be ported to Mac and Linux. Is your colorizing stuff able to be separated out? I could see about putting it into my Qt based editor if so. For those people that must have that PropTool look.
The way I have setup the OpenSpin code, you could easily make it into a library or even DLL. Then you can link it into your editor and call it for compiles and make your editor work exactly like PropTool for compiling (even compiling from the code in the open editor tab without saving). I have an alternate "wrapper" locally that I did for my editor (that's unfinished and may never be) that I'd be fine with sharing with you if you want to integrate it into your editor.
I'd suggest leaving the compiler as a standalone program. That has a number of advantages: it lets the editor work with any Spin compiler (such as fastspin or bstc), and makes it easy to extend for Spin2 or when other new Spin compilers come along. It also should make porting to other platforms easier -- the Mac and Linux do have DLLs, but they're a bit different from Windows and trying to support DLLs on all the different platforms is probably harder than just having a way to call an external program.
I'd suggest leaving the compiler as a standalone program. That has a number of advantages: it lets the editor work with any Spin compiler (such as fastspin or bstc), and makes it easy to extend for Spin2 or when other new Spin compilers come along. It also should make porting to other platforms easier -- the Mac and Linux do have DLLs, but they're a bit different from Windows and trying to support DLLs on all the different platforms is probably harder than just having a way to call an external program.
I'd agree - it's also easier to update the compilers...
Other Editors/IDE capture the compiler outputs, and many include a simple error-report parser, so you can jump-to-error in the editor.
It's common to have a simple scan-filter setup there for users (eg Notepad++ does this)
eg if a compiler reports
FileName(LineNumber) error ErrNum : Error Text
you test for ") error " on any line, and then extract the other info to jump the editor.
ersmith,
One of the features of PropTool is compiling code from the version(s) that is/are in the editor window(s) without saving. While you could do this with some temp files and temp mods to the source to use the temp file names in OBJ declarations, that is a lot trickier than just passing the buffers to the compiler as needed. Some people really like this feature. I'm used to the idea that compiling causes all files to be saved, since that is what VS does and most other IDEs too. OpenSpin will always have the command line version, but it's arranged such that you can use it as a library too.
Another thing that can be done with it as a library is "intellisense" like features. Where the compiler can give you all the symbols and some other info that you can use for highlighting and completion among other things. Even if it wasn't ever used for the actual compile, it's still handy to have built into the editor.
One of the features of PropTool is compiling code from the version(s) that is/are in the editor window(s) without saving. While you could do this with some temp files and temp mods to the source to use the temp file names in OBJ declarations, that is a lot trickier than just passing the buffers to the compiler as needed. Some people really like this feature.
Hmm, sounds actually quite dangerous, and not something any commercial user would want to touch. If someone really wants to fork a design to play, use 'save-as'.
Another thing that can be done with it as a library is "intellisense" like features. Where the compiler can give you all the symbols and some other info that you can use for highlighting and completion among other things. Even if it wasn't ever used for the actual compile, it's still handy to have built into the editor.
I've seen some 'find declaration' abilities in IDEs, but there I think the editor includes a simple parser, - but maybe that's what you are meaning ?
More useful is to have Symbol support include value inspect in debug, and that's usually done via a Symbol file, that has final located address info. That needs a compile pass to generate that info.
In another thread I posted an example of SASM IDE which is ASM aware highlighting, but includes Debug Abilities.
There is also https://github.com/platformio, claims to support VS Code and Atom, and claims Debug abilities, but it seems Debug may be $$ ?
One of the features of PropTool is compiling code from the version(s) that is/are in the editor window(s) without saving.
and...
Hmm, sounds actually quite dangerous, and not something any commercial user would want to touch.
I thought both these things, however having used the feature and having introduced it, and the Prop generally to some users unfamiliar with them, and revision control, it's a KILLER FEATURE.
Compile from disk means saving all code state changes, then building, then executing. Then, one makes another code state change, repeat right?
The idea being what you are typing isn't final or useful in any real way, until saved and processed.
Fair enough. We all know how to do that.
But, what happens when you aren't sure of what you are typing? Worse, what happens when you just are not sure at all?
Of course, there are a few options:
Get sure. This takes time, often assistance, learned skill. It won't happen right away. It not happening can be very discouraging.
Get help. This takes another person, time, and sometimes assistance. It too is very much a learned skill.
Or, futz with it, until you get somewhere!
Now, in this scenario, one can invert the workflow, and with it, see a new perspective.
Say one has a sample program, driver, whatever. You run it, want to tinker with it, just explore some. Doing that, with the build from disk scenario requires you either change it, copy it somewhere to be changed, or make use of revision control tools that manage doing those things. The barrier for entry, learning, testing, just went way up. And, it's possible to break it all on one's very first exploratory code change too. No returns, unless skills have been learned pre-fact. And that almost never happens.
On the other hand, if you are building from RAM, doing this is super easy. Edit it, hit the button, see the outcome. Low barrier. While it remains true, one's first edit could break everything, "reload all files", is super easy, and a working state is returned with low effort.
As a bonus, one can consider the state on disk, ideally a series of states on disk, as milestones, rather than attempts. There are fewer of them written out, generally speaking. That does vary widely among people and projects.
Write it, run it, does it work?
No?
Change it. Does it work?
Yes.
Great, save that. Ideally, as a new version, but could just be a new working state for something simple.
Add to it, change it, whatever, does it work?
No.
Bail, revert to saved disk state.
Wash, rinse, repeat.
My point here is build from RAM vs build from disk being good or bad, is largely a matter of perspective and one's workflow.
There are great, perfectly suitable workflows that fall out of building from RAM, just as there are great, perfectly suitable workflows falling out of build from disk.
What build from disk doesn't get you is a temporary working state for basically free. Build from RAM does.
For some newbies, the idea of just not saving it, unless it makes sense, is a low entry barrier workflow. And the beauty of it done that way is that introducing revision control doesn't get in the way of learning, testing, exploring as it's only going to make the "save it to continue building" use case more robust!
There simply is more to manage on exploratory edits and additions with the "save to build" use cases. Making a new state to explore something more or less has to be planned in advance. Or, one has to have a good grasp on revision control, or ideally both. Without these, one can only build what has been written out as some state that is no longer live to the user.
In the "build what you see", or "build from RAM" use case, doing all that is implied. Can't avoid doing it. Thinking that way is a perspective shift, but often a less laborious one, depending on how one chooses to work and why.
It's a feature worth having, IMHO.
I'm not making a "this is better" type argument. Both can be robust, given the right mindset. I am making an "options are good" argument, as one size rarely fits all here.
Seems to me, what Roy did was provide for both. People like options. Anyone who wants a standalone compilier gets one, and having a very tightly integrated, "just push the button to run it, all right out of RAM, if you want to", remains possible.
Sort of OT but someone asked what BSTC can do that OpenSpin can't. Regarding PropBasic the only compilers that can handle the @ @ @ are BSTC and HomeSpun. I'm pretty sure the OpenSpin author wasn't amenable to adding that feature into OpenSpin. Yes I know the "@"s are not supposed to have intervening spaces. The forum software is a bit weird.
For an analogy, consider only being able to print saved documents in various word processors / editors.
People, used to doing things "the usual way", build from RAM makes sense. More, better, different skills can be learned later, and for those who need them, they will too.
That said, just doing it the way one might expect has a lot of merit, where barrier to entry, number of things one has to know in order to write a program are concerned.
I like the idea of bringing in OpenSpin source to the project... I don't think it'd be hard to have OpenSpin, Brad's and Propellent as options...
I think I can also have the same program support both Spin1 and Spin2. This is a MDI app and can support different document types...
What is missing from OpenSpin that would allow it to completely replace BSTC?
I think triple at sign (absolute data address) is missing from OpenSpin. PropBasic, at least, needs that. fastspin will work as a bstc replacement for PropBasic, since it does support triple at. Since the PropBasic program is all PASM (except for a very very tiny Spin launcher that's fixed size) the fastspin LMM overhead is negligible.
I'll also point out that fastspin already supports part of Spin2, so I'd definitely suggest providing a way for a Spin2 editor to support it. fastspin.exe is designed to be compatible with openspin.exe. Unfortunately there's no DLL for fastspin at the moment. OTOH I don't see shared library support for openspin on anything other than Windows, so again, supporting command line tools will be good for cross platform support.
Write it, run it, does it work?
No?
Change it. Does it work?
Yes.
Great, save that. Ideally, as a new version, but could just be a new working state for something simple.
Add to it, change it, whatever, does it work?
No.
Bail, revert to saved disk state.
Wash, rinse, repeat.
Yes, I can see the futz-about appeal, but (for example) Notepad++ allows undo's across file-saves, which gives an almost identical unravel ability, without the risks.
Save-as is also so simple, if you do want to fork, and I often do that ....
Undo is interesting... This has a hard coded undo feature that I was about to replace with a regular one. But, I just checked and undo is preserved after a save. Maybe that's work keeping...
You have to do ctrl-z, ctrl-a for undo, redo at the moment...
Write it, run it, does it work?
No?
Change it. Does it work?
Yes.
Great, save that. Ideally, as a new version, but could just be a new working state for something simple.
Add to it, change it, whatever, does it work?
No.
Bail, revert to saved disk state.
Wash, rinse, repeat.
Yes, I can see the futz-about appeal, but (for example) Notepad++ allows undo's across file-saves, which gives an almost identical unravel ability, without the risks.
Save-as is also so simple, if you do want to fork, and I often do that ....
Again, I'm not making a "better" argument, instead an "options are good" one, so as to gain the benefits for those users who would value them.
ersmith: What are you using for your fastspin GUI? I'm assuming it is cross platform.
spin2gui is written in Tcl/Tk, so yes, it's cross platform. The editor is the weak point though; it's nowhere near as nice as the one Rayman is working on. It would be great to have a more powerful (and cross platform) Spin2 editor.
Undo is interesting... This has a hard coded undo feature that I was about to replace with a regular one. But, I just checked and undo is preserved after a save. Maybe that's work keeping...
You have to do ctrl-z, ctrl-a for undo, redo at the moment...
I've certainly found undo across file saves very nice to have..., so yes, that's worth keeping. That will then be very close to ram-compile.
The other useful feature in Notepad++, is a column mode editor, where you can paste/type into many vertical rows at the same time. A variant menu on this allows numeric dec/hex entry into those selected rows. eg 1..9 on 9 lines.
Yeah, the primary thing OpenSpin doesn't do of BSTC's features is the triple @ one. It's really tricky to do given the way chip's original compiler (that I ported) works. I do still want to support that eventually, but it requires some significant rework to support. The main thing I ran into was that it has to work with expressions and pretty much everywhere, and that requires recompiling (or at least keeping track of and patching it) certain bits of the bytecode very late, after the final image layout is know) the way things currently work with Chip's method (which doesn't have the final memory layout until basically the very last step).
I like undo across saves, it's super handy. I'd really like undo across sessions, but no editor I know of has that.
Ray, undo/redo should be ctrl-z / ctrl-y in order to be standard. ctrl-a should be select all text (whole file's text).
jmg/potatohead, the whole compile from memory thing is a feature I rarely use (and never really intentionally),but some people REALLY like it. I very much prefer the save and compile functionality that is pretty standard everywhere else, and with undo across saves it's basically a moot point.
The editor I was working on is very much like PropTool in function, just not with the coloring and tabbing stuff (which is more "normal" on mine). It's using Qt, so cross platform to almost everything.
It's working reasonably well as an editor (since most of that came with Qt for free), just doesn't do much of the IDE type stuff yet.
I started on it months ago when no one was working on any editor/ide stuff, now it seems like everyone has an editor in the works, so I set it aside.
I like undo across saves, it's super handy. I'd really like undo across sessions, but no editor I know of has that.
I used some software once that just implemented a session file. Dump the entire working state in there and the undo across sessions is an artifact of doing that.
One thing I really like is that open files in Propeller Tool are used first.
So I have my project open at whatever/project/
and it contains sdspi.spin inside that folder. Now I have whatever/project/test/ with another version (newer?better?worse?) of the same file.
if I have the never file (in different directory) open in the PropTool, a compile will use the currently open file, not the file in the project directory. I really LOVE that, without changing files in your project directory, you can test-run changes easy.
Comments
OpenSpin's unused code elimination does more than BSTC's does, so in many cases the results are smaller. For example OpenSpin can remove an entire object if none of the methods are called (and still allows you to use CON stuff from the removed object since those are just compile time symbols).
Dave Hein,
Pretty sure OpenSpin can deal with that (as long as the end result fits). If also has an option to allow you to make eeprom files larger than 32k.
The way I have setup the OpenSpin code, you could easily make it into a library or even DLL. Then you can link it into your editor and call it for compiles and make your editor work exactly like PropTool for compiling (even compiling from the code in the open editor tab without saving). I have an alternate "wrapper" locally that I did for my editor (that's unfinished and may never be) that I'd be fine with sharing with you if you want to integrate it into your editor.
Pity you are making it in such a way that it's windows only. You really should look into something that can at least be ported to Mac and Linux. Is your colorizing stuff able to be separated out? I could see about putting it into my Qt based editor if so. For those people that must have that PropTool look.
I'd suggest leaving the compiler as a standalone program. That has a number of advantages: it lets the editor work with any Spin compiler (such as fastspin or bstc), and makes it easy to extend for Spin2 or when other new Spin compilers come along. It also should make porting to other platforms easier -- the Mac and Linux do have DLLs, but they're a bit different from Windows and trying to support DLLs on all the different platforms is probably harder than just having a way to call an external program.
Eric
Other Editors/IDE capture the compiler outputs, and many include a simple error-report parser, so you can jump-to-error in the editor.
It's common to have a simple scan-filter setup there for users (eg Notepad++ does this)
eg if a compiler reports
FileName(LineNumber) error ErrNum : Error Text
you test for ") error " on any line, and then extract the other info to jump the editor.
One of the features of PropTool is compiling code from the version(s) that is/are in the editor window(s) without saving. While you could do this with some temp files and temp mods to the source to use the temp file names in OBJ declarations, that is a lot trickier than just passing the buffers to the compiler as needed. Some people really like this feature. I'm used to the idea that compiling causes all files to be saved, since that is what VS does and most other IDEs too. OpenSpin will always have the command line version, but it's arranged such that you can use it as a library too.
Another thing that can be done with it as a library is "intellisense" like features. Where the compiler can give you all the symbols and some other info that you can use for highlighting and completion among other things. Even if it wasn't ever used for the actual compile, it's still handy to have built into the editor.
Yes, that is the more sane/common approach...
I've seen some 'find declaration' abilities in IDEs, but there I think the editor includes a simple parser, - but maybe that's what you are meaning ?
More useful is to have Symbol support include value inspect in debug, and that's usually done via a Symbol file, that has final located address info. That needs a compile pass to generate that info.
In another thread I posted an example of SASM IDE which is ASM aware highlighting, but includes Debug Abilities.
There is also https://github.com/platformio, claims to support VS Code and Atom, and claims Debug abilities, but it seems Debug may be $$ ?
I think I can also have the same program support both Spin1 and Spin2. This is a MDI app and can support different document types...
I think OpenSpin is written with Visual Studio, so I could bring the code in.
I think it could then run on Mac using WINE.
and...
I thought both these things, however having used the feature and having introduced it, and the Prop generally to some users unfamiliar with them, and revision control, it's a KILLER FEATURE.
Compile from disk means saving all code state changes, then building, then executing. Then, one makes another code state change, repeat right?
The idea being what you are typing isn't final or useful in any real way, until saved and processed.
Fair enough. We all know how to do that.
But, what happens when you aren't sure of what you are typing? Worse, what happens when you just are not sure at all?
Of course, there are a few options:
Get sure. This takes time, often assistance, learned skill. It won't happen right away. It not happening can be very discouraging.
Get help. This takes another person, time, and sometimes assistance. It too is very much a learned skill.
Or, futz with it, until you get somewhere!
Now, in this scenario, one can invert the workflow, and with it, see a new perspective.
Say one has a sample program, driver, whatever. You run it, want to tinker with it, just explore some. Doing that, with the build from disk scenario requires you either change it, copy it somewhere to be changed, or make use of revision control tools that manage doing those things. The barrier for entry, learning, testing, just went way up. And, it's possible to break it all on one's very first exploratory code change too. No returns, unless skills have been learned pre-fact. And that almost never happens.
On the other hand, if you are building from RAM, doing this is super easy. Edit it, hit the button, see the outcome. Low barrier. While it remains true, one's first edit could break everything, "reload all files", is super easy, and a working state is returned with low effort.
As a bonus, one can consider the state on disk, ideally a series of states on disk, as milestones, rather than attempts. There are fewer of them written out, generally speaking. That does vary widely among people and projects.
Write it, run it, does it work?
No?
Change it. Does it work?
Yes.
Great, save that. Ideally, as a new version, but could just be a new working state for something simple.
Add to it, change it, whatever, does it work?
No.
Bail, revert to saved disk state.
Wash, rinse, repeat.
My point here is build from RAM vs build from disk being good or bad, is largely a matter of perspective and one's workflow.
There are great, perfectly suitable workflows that fall out of building from RAM, just as there are great, perfectly suitable workflows falling out of build from disk.
What build from disk doesn't get you is a temporary working state for basically free. Build from RAM does.
For some newbies, the idea of just not saving it, unless it makes sense, is a low entry barrier workflow. And the beauty of it done that way is that introducing revision control doesn't get in the way of learning, testing, exploring as it's only going to make the "save it to continue building" use case more robust!
There simply is more to manage on exploratory edits and additions with the "save to build" use cases. Making a new state to explore something more or less has to be planned in advance. Or, one has to have a good grasp on revision control, or ideally both. Without these, one can only build what has been written out as some state that is no longer live to the user.
In the "build what you see", or "build from RAM" use case, doing all that is implied. Can't avoid doing it. Thinking that way is a perspective shift, but often a less laborious one, depending on how one chooses to work and why.
It's a feature worth having, IMHO.
I'm not making a "this is better" type argument. Both can be robust, given the right mindset. I am making an "options are good" argument, as one size rarely fits all here.
Seems to me, what Roy did was provide for both. People like options. Anyone who wants a standalone compilier gets one, and having a very tightly integrated, "just push the button to run it, all right out of RAM, if you want to", remains possible.
What's not to like?
---Mike R...
People, used to doing things "the usual way", build from RAM makes sense. More, better, different skills can be learned later, and for those who need them, they will too.
That said, just doing it the way one might expect has a lot of merit, where barrier to entry, number of things one has to know in order to write a program are concerned.
I think triple at sign (absolute data address) is missing from OpenSpin. PropBasic, at least, needs that. fastspin will work as a bstc replacement for PropBasic, since it does support triple at. Since the PropBasic program is all PASM (except for a very very tiny Spin launcher that's fixed size) the fastspin LMM overhead is negligible.
I'll also point out that fastspin already supports part of Spin2, so I'd definitely suggest providing a way for a Spin2 editor to support it. fastspin.exe is designed to be compatible with openspin.exe. Unfortunately there's no DLL for fastspin at the moment. OTOH I don't see shared library support for openspin on anything other than Windows, so again, supporting command line tools will be good for cross platform support.
Eric
Yes, I can see the futz-about appeal, but (for example) Notepad++ allows undo's across file-saves, which gives an almost identical unravel ability, without the risks.
Save-as is also so simple, if you do want to fork, and I often do that ....
You have to do ctrl-z, ctrl-a for undo, redo at the moment...
Again, I'm not making a "better" argument, instead an "options are good" one, so as to gain the benefits for those users who would value them.
spin2gui is written in Tcl/Tk, so yes, it's cross platform. The editor is the weak point though; it's nowhere near as nice as the one Rayman is working on. It would be great to have a more powerful (and cross platform) Spin2 editor.
I've certainly found undo across file saves very nice to have..., so yes, that's worth keeping. That will then be very close to ram-compile.
The other useful feature in Notepad++, is a column mode editor, where you can paste/type into many vertical rows at the same time. A variant menu on this allows numeric dec/hex entry into those selected rows. eg 1..9 on 9 lines.
Alt-mouse-drag sets the columns or box.
I like undo across saves, it's super handy. I'd really like undo across sessions, but no editor I know of has that.
Ray, undo/redo should be ctrl-z / ctrl-y in order to be standard. ctrl-a should be select all text (whole file's text).
jmg/potatohead, the whole compile from memory thing is a feature I rarely use (and never really intentionally),but some people REALLY like it. I very much prefer the save and compile functionality that is pretty standard everywhere else, and with undo across saves it's basically a moot point.
It's working reasonably well as an editor (since most of that came with Qt for free), just doesn't do much of the IDE type stuff yet.
I started on it months ago when no one was working on any editor/ide stuff, now it seems like everyone has an editor in the works, so I set it aside.
I used some software once that just implemented a session file. Dump the entire working state in there and the undo across sessions is an artifact of doing that.
So I have my project open at whatever/project/
and it contains sdspi.spin inside that folder. Now I have whatever/project/test/ with another version (newer?better?worse?) of the same file.
if I have the never file (in different directory) open in the PropTool, a compile will use the currently open file, not the file in the project directory. I really LOVE that, without changing files in your project directory, you can test-run changes easy.
Mike