Whatever the IDE looks like, I recommend always keeping the compiler as a separate executable that is run up by the IDE for each compile, and just as easily run by hand in a regular shell. Same for the programmer, eg: loadp2.
I've come to enjoy using a shell since working with the Prop2.
David Betz,
PropTool is written in Delphi and uses some closed source libs or something. Porting it out to a reasonable language would be kind of silly. The better path to take would be to make something new from scratch using Qt. You can get a reasonable IDE up and running in Qt in a couple days, I've done the basics a couple times but then gave up because it was easier to just use VS Code or notepad++ for myself.
There needs to be an open source cross platform IDE/compiler that is official, and it needs to be available at launch.
Yes, a clean implementation would probably be best. I was just thinking that many people here seem to love the PropellerTool and it's simple enough that it might not be too hard to translate it from Delphi into C and use the Qt widgets to implement the UI. On the other hand, the fact that it's simple probably means recreating it from scratch wouldn't be that hard either. I don't suggest starting with either SimpleIDE or PropellerIDE though.
I've come to enjoy using a shell since working with the Prop2.
Yes!! Finally some appreciation of command line tools. I've been using them forever. I wouldn't want to give up a GUI editor though. Going back to TECO or SOS would be way too painful.
GUI all the way. Lots of windows, including multiple shell consoles, spread all around a large desktop. I'm using Kate for my editor right now. It has the all important block select mode I loved on the Amiga with Cygnus Ed.
GUI all the way. Lots of windows, including multiple shell consoles, spread all around a large desktop. I'm using Kate for my editor right now. It has the all important block select mode I loved on the Amiga with Cygnus Ed.
I have always called on Kate to handle block select but I loaded a block select package into Atom editor and that worked a treat too.
If we had official command line tools that had open source code in theory we should able to recompile and use them on different platforms such as Mac and Linux in addition to Windows. These days IDEs are a dime a dozen, though I agree in a Windows environment that Prop Tool was pretty easy to use when I was a beginner getting started with the P1 in the early days. Once I moved to Linux and Mac OS X one of the more annoying things with running separate tools was that the download and serial port console access sharing the same port became problematic. Doing Propeller downloads in Linux using BST without closing the terminal first then respawning it each time was always a PITA so an all-in-one setup which can seamlessly download then switch the serial port over for use as a console is nice. I guess that sort of integrated system level control may become harder to achieve consistently over different platforms when the tools get split up. I did very much like the cross platform PropellerIDE until BST broke with later OSX versions and PropellerIDE essentially became abandonware when the author no longer wanted to continue it.
If we had official command line tools that had open source code in theory we should able to recompile and use them on different platforms such as Mac and Linux in addition to Windows. These days IDEs are a dime a dozen, though I agree in a Windows environment that Prop Tool was pretty easy to use when I was a beginner getting started with the P1 in the early days. Once I moved to Linux and Mac OS X one of the more annoying things with running separate tools was that the download and serial port console access sharing the same port became problematic. Doing Propeller downloads in Linux using BST without closing the terminal first then respawning it each time was always a PITA so an all-in-one setup which can seamlessly download then switch the serial port over for use as a console is nice. I guess that sort of integrated system level control may become harder to achieve consistently over different platforms when the tools get split up. I did very much like the cross platform PropellerIDE until BST broke with later OSX versions and PropellerIDE essentially became abandonware when the author no longer wanted to continue it.
I found that I didn't need to close the terminal itself, but by going into the port menu I found that minicom releases the port. So <ctrL>A,P then hit F11 on BST and when it is done just escape the minicom menu. Other terminals may also do this.
But yes, I agree, give use CLI tools first.
If we had official command line tools that had open source code in theory we should able to recompile and use them on different platforms such as Mac and Linux in addition to Windows. These days IDEs are a dime a dozen, though I agree in a Windows environment that Prop Tool was pretty easy to use when I was a beginner getting started with the P1 in the early days. Once I moved to Linux and Mac OS X one of the more annoying things with running separate tools was that the download and serial port console access sharing the same port became problematic. Doing Propeller downloads in Linux using BST without closing the terminal first then respawning it each time was always a PITA so an all-in-one setup which can seamlessly download then switch the serial port over for use as a console is nice. I guess that sort of integrated system level control may become harder to achieve consistently over different platforms when the tools get split up. I did very much like the cross platform PropellerIDE until BST broke with later OSX versions and PropellerIDE essentially became abandonware when the author no longer wanted to continue it.
I seem to recall Ken Gracey saying a while back that Parallax wanted to get out of the IDE business so I suspect integration with some existing IDE will be the way they will go eventually.
When working with PropBasic and the terminal using terraterm- altn connects and alti disconnects. Just needed a delay at the start of the program to give the couple of seconds to do that.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
I didn't know we had such a problem, but, yes, we would like to make it work with whatever's out there. I hate how so much complexity has been injected into everything nowadays.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
I didn't know we had such a problem, but, yes, we would like to make it work with whatever's out there. I hate how so much complexity has been injected into everything nowadays.
If you want to avoid complexity, please avoid Qt. Sure, it makes stuff easy to get stuff working quickly, but it takes up a monstrous amount of disk space, and it's often difficult to get things to compile because it has so many dependencies. If you're going to write a new Spin IDE, please use some other, any other framework to do it in. For example, Scintilla is a cross-platform syntax-highlighting text editing widget you could use instead of Qt.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
Whatever the IDE looks like, I recommend always keeping the compiler as a separate executable that is run up by the IDE for each compile, and just as easily run by hand in a regular shell.
Same for the programmer, eg: loadp2.
Yes, Compiler and Downloader should be clearly named, and separate programs.
That allows any shell/gui to be used.
Chip,
Are you really going to get PropTool updated with Spin2???
I know it just works, but it it lacks even the basic of features like conditional compile, etc. Surely we can give it a miss and move on to something better??? There is Eric's fastspin. We can use Visual Studio Code to edit which is open source and cross platform. Then there is OpenSpin which Roy is likely to update.
It is something that Parallax wrote and has complete knowledge of. So, that is our primary platform.
That's a bit worrying, what exactly does "that is our primary platform"mean ?
I can see the appeal to support legacy PropTool users and give them a P2 pathway.
However, if primary platform means Parallax says all they support is PropTool, with a long 'to fix/to do' list, that will certainly hold back P2.
Parallax does not need 'something that Parallax wrote and has complete knowledge of' to use Visual Studio Code, they just need to provide working examples.
For most GUIs, that support would start with Syntax Highlighter files, and batch files.
At the risk at repeating myself again, what is wrong with Visual Studio Code?
It’s just a free open sourced (from Microsoft) that I believe runs on multiple platforms. I’ve done the basic syntax highlighting plugin for pasm, pasm2 and spin. It is quite capable of calling a compiler and downloader, and it has its own terminal inbuilt. According to research, it’s the most used/supported code editor around.
These days, everyone has their favourite editor. No need to reinvent the wheel again, or worse, used an outdated single platform featureless tool such as PropTool. Yes, I love it but it’s never going to be enhanced to overcome its shortcomings.
PropTool does not even have basic conditional compile despite the request (or demands) for 10 years. We’ve been told its archaic and will not be refreshed. Time to let it die Chip!!!
By separating the compiler/loader, we can utilise other resources better. There is Erics fastspin or Roys Openspin that should be enhanced. Chip, please take one of these and support it. We can use our “favourite” editor to edit the code.
FWIW, I use PropTool to edit pasm2 (p2 source I rename spin from spin2) just for the highlighting due to old habits. I need to move on too!!!
There is a thread that i started about Visual Studio Code and spin highlighting, including pics IIRC. VSC supports many languages via plugins (extensions) including Python, C, etc etc. VSC can support intelisense too.
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
I didn't know we had such a problem, but, yes, we would like to make it work with whatever's out there. I hate how so much complexity has been injected into everything nowadays.
If you want to avoid complexity, please avoid Qt. Sure, it makes stuff easy to get stuff working quickly, but it takes up a monstrous amount of disk space, and it's often difficult to get things to compile because it has so many dependencies. If you're going to write a new Spin IDE, please use some other, any other framework to do it in. For example, Scintilla is a cross-platform syntax-highlighting text editing widget you could use instead of Qt.
Thanks for the Scintilla tip. That looks good. Any idea how big it is?
I have used Qt quite a lot for cross platform tools. Yes, the Qt SDK and tools is quite large on disk, but the results you make with it do not have to be. I think you would be making a mistake to not use it for cross platform tools.
I've never had issue with dependencies or compiling with it beyond what is normal for any cross platform SDK, and once your project is setup it's not like you have to keep dealing with that?!
Anyway, I like PropTool, but it's windows only, written in an obsolete language, and closed source. It's absolutely the wrong thing to continue going with... and it's super frustrating that we are even having this discussion.
Chip, what you should be doing is working on making the compiler a stand alone command line tool. Make it work without any of the editor/downloader/etc. Smile. just make it take source files and include paths and compile the code to a binary.
Then make a downloader tool (again command line) that will take a binary and send it to an attached P2. If you make those two things, then they can be used with literally any of hundreds of existing editors/IDEs.
I have used Qt quite a lot for cross platform tools. Yes, the Qt SDK and tools is quite large on disk, but the results you make with it do not have to be. I think you would be making a mistake to not use it for cross platform tools.
I've never had issue with dependencies or compiling with it beyond what is normal for any cross platform SDK, and once your project is setup it's not like you have to keep dealing with that?!
Anyway, I like PropTool, but it's windows only, written in an obsolete language, and closed source. It's absolutely the wrong thing to continue going with... and it's super frustrating that we are even having this discussion.
Walk before run. PropellerTool will get Spin2 walking and running.
I'm getting multiple return values hashed out today for Spin2. This removes a constraint in programming that I suppose many of us have long since sublimated into our thinking.
Chip, what you should be doing is working on making the compiler a stand alone command line tool. Make it work without any of the editor/downloader/etc. Smile. just make it take source files and include paths and compile the code to a binary.
Then make a downloader tool (again command line) that will take a binary and send it to an attached P2. If you make those two things, then they can be used with literally any of hundreds of existing editors/IDEs.
Chip,
Since you didn't quote this part (above), I assume you missed it. This is the path to get Spin2 walking and running. This is the path that makes the most sense.
Chip, what you should be doing is working on making the compiler a stand alone command line tool. Make it work without any of the editor/downloader/etc. Smile. just make it take source files and include paths and compile the code to a binary.
Then make a downloader tool (again command line) that will take a binary and send it to an attached P2. If you make those two things, then they can be used with literally any of hundreds of existing editors/IDEs.
Chip,
Since you didn't quote this part (above), I assume you missed it. This is the path to get Spin2 walking and running. This is the path that makes the most sense.
Yes, okay. I've been asked about this before. It's doable, of course. Just need to do it once things are running.
Chip, what you should be doing is working on making the compiler a stand alone command line tool. Make it work without any of the editor/downloader/etc. Smile. just make it take source files and include paths and compile the code to a binary.
Then make a downloader tool (again command line) that will take a binary and send it to an attached P2. If you make those two things, then they can be used with literally any of hundreds of existing editors/IDEs.
Chip,
Since you didn't quote this part (above), I assume you missed it. This is the path to get Spin2 walking and running. This is the path that makes the most sense.
Yes, okay. I've been asked about this before. It's doable, of course. Just need to do it once things are running.
Do the Spin 2 compiler and the separate downloader, not already have command line versions ?
If the propeller tool is going to be revisited in code, might there be time to investigate the long standing bug that prevents large programs from being uploaded to a propeller over anything other than a FutureTech FT23x chip?
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
A program (as viewed in the object info window) of 4195 longs or less works fine when uploading to a propeller.
A program of 4196 or greater throws up a "Write Failure on COMx".
Other propeller programming tools don't have this problem with the CH340.
If memory serves, the SiLabs CP2102 exhibits the same behavior when used with Propeller Tool.
There have been several discussions about this over the years in the Prop 1 forum.
Chip, let me know where and to who's attn to send one of these prop plugs to. I'll have it in the mail tomorrow.
Do the Spin 2 compiler and the separate downloader, not already have command line versions ?
@"Dave Hein" already has quite a nice downloader in the form of the "loadp2" program. Why don't we use that? It's open source, portable (runs on Windows, Mac, and Linux) and tested in the field a lot already.
I'd certainly agree that a command line version of Chip's Spin2 compiler should be a priority.
Do the Spin 2 compiler and the separate downloader, not already have command line versions ?
@"Dave Hein" already has quite a nice downloader in the form of the "loadp2" program. Why don't we use that? It's open source, portable (runs on Windows, Mac, and Linux) and tested in the field a lot already.
I'd certainly agree that a command line version of Chip's Spin2 compiler should be a priority.
Yes, and that is asked a lot about the PropTool, just give it some command line parameter to be called with as a start. Still is 86 assembler+Delphi and not portable, but One could call it from some other editor.
Better even let the Proptool call a external compiler and loader, so one could call fastspin instead of byte code from inside the proptool if wanted.
Make PropTool a IDE, separate compiler and loader from it. Spin2Gui (just typed Spin2Guy, what a Sigmund Freud thing) does this simple and nice, just put the same dialog options into the PropTool Menu.
All of us here have to accept that Chip wants his own code running his own P2, It is the 'I did all of it' mentality, and there is nothing wrong with that. Because he did and can be effing proud of himself, and he should be.
Changing PropTool to configure compiler and loader used externally, would combine this. Not hard for Chip to do, he has his way, we can use his compiler, Roy's compiler, Fastspin, whatever.
Does P2load currently support the WIFI loading option used by Blockly and the WX boards? If not this should be merged from the P1loader to make this available for future P2 boards.
Just reduce complexity and support problems by using the same tools on all platforms, fastspin uses p2load, Catalina seems to do, PropGcc seems to do and PropTool should also. Once support has that running they can check off - loader works, next step... independent if C, Basic, Spin, whatever is used. If it works for Spin it works for C, it works for Basic...
And if I would like to use Kolibri-Os as dev platform (I don't) I could compile the cmd-line-tools and be up and running, even with parallax support able to help me.
This just makes more sense as all integrated in PropTool and everything else uses different loaders.
Chip, please, separate byte-code-compiler, loader and OropTool into single executables with cmd-line parameters.
I applaud the continuation of Prop Tool into the P2 domain. Prop Tool is drop-dead easy to use, thus being a easy on-ramp for P1 and P2 apps. Other stuff can come later, but Prop Tool needs to be the canonical standard against which all other IDEs are compared. Its closed-sourcedness is much less important than the continuity it provides to P1 users transitioning to the P2.
I applaud the continuation of Prop Tool into the P2 domain. Prop Tool is drop-dead easy to use, thus being a easy on-ramp for P1 and P2 apps. Other stuff can come later, but Prop Tool needs to be the canonical standard against which all other IDEs are compared. Its closed-sourcedness is much less important than the continuity it provides to P1 users transitioning to the P2.
Agreed, but this is not an either/or equation.
PropTool.2019 can do all of that, and it can include command line compilers and command line download.
A single closed binary-blob is very poor for software upgrades. (just look at the date on PropTool and the bug-list...)
Comments
Code::Blocks is an option worth investigating. Already supports both GCC and Catalina, and very easy to add other new compilers.
I've come to enjoy using a shell since working with the Prop2.
I have always called on Kate to handle block select but I loaded a block select package into Atom editor and that worked a treat too.
I found that I didn't need to close the terminal itself, but by going into the port menu I found that minicom releases the port. So <ctrL>A,P then hit F11 on BST and when it is done just escape the minicom menu. Other terminals may also do this.
But yes, I agree, give use CLI tools first.
When working with PropBasic and the terminal using terraterm- altn connects and alti disconnects. Just needed a delay at the start of the program to give the couple of seconds to do that.
Dave
I am willing to supply Parallax with a prop-plug based on the CH340 UART for testing.
I didn't know we had such a problem, but, yes, we would like to make it work with whatever's out there. I hate how so much complexity has been injected into everything nowadays.
If you want to avoid complexity, please avoid Qt. Sure, it makes stuff easy to get stuff working quickly, but it takes up a monstrous amount of disk space, and it's often difficult to get things to compile because it has so many dependencies. If you're going to write a new Spin IDE, please use some other, any other framework to do it in. For example, Scintilla is a cross-platform syntax-highlighting text editing widget you could use instead of Qt.
All that set, none of the open arguments here are invalidated by any of that. Both can happen. And I think they should.
What we get for that, what looks like low effort affair, is a super easy start for a lot of casual P1 users looking at P2. Total win.
What does 'large' mean here ?
Do you have more details on what fails, and how it fails ?
Using USB-UARTs, I've only seen one issue with download size, and that is in EXAR drivers themselves, with a single file send of > 500kBytes.
There are of course issues with download speed, and half duplex vs full duplex vs echo.. but usually you have to be well over 1MBd to hit those.
That allows any shell/gui to be used.
Valid points...
That's a bit worrying, what exactly does "that is our primary platform"mean ?
I can see the appeal to support legacy PropTool users and give them a P2 pathway.
However, if primary platform means Parallax says all they support is PropTool, with a long 'to fix/to do' list, that will certainly hold back P2.
Parallax does not need 'something that Parallax wrote and has complete knowledge of' to use Visual Studio Code, they just need to provide working examples.
For most GUIs, that support would start with Syntax Highlighter files, and batch files.
It’s just a free open sourced (from Microsoft) that I believe runs on multiple platforms. I’ve done the basic syntax highlighting plugin for pasm, pasm2 and spin. It is quite capable of calling a compiler and downloader, and it has its own terminal inbuilt. According to research, it’s the most used/supported code editor around.
These days, everyone has their favourite editor. No need to reinvent the wheel again, or worse, used an outdated single platform featureless tool such as PropTool. Yes, I love it but it’s never going to be enhanced to overcome its shortcomings.
PropTool does not even have basic conditional compile despite the request (or demands) for 10 years. We’ve been told its archaic and will not be refreshed. Time to let it die Chip!!!
By separating the compiler/loader, we can utilise other resources better. There is Erics fastspin or Roys Openspin that should be enhanced. Chip, please take one of these and support it. We can use our “favourite” editor to edit the code.
FWIW, I use PropTool to edit pasm2 (p2 source I rename spin from spin2) just for the highlighting due to old habits. I need to move on too!!!
There is a thread that i started about Visual Studio Code and spin highlighting, including pics IIRC. VSC supports many languages via plugins (extensions) including Python, C, etc etc. VSC can support intelisense too.
just my 2c
Thanks for the Scintilla tip. That looks good. Any idea how big it is?
I've never had issue with dependencies or compiling with it beyond what is normal for any cross platform SDK, and once your project is setup it's not like you have to keep dealing with that?!
Anyway, I like PropTool, but it's windows only, written in an obsolete language, and closed source. It's absolutely the wrong thing to continue going with... and it's super frustrating that we are even having this discussion.
Chip, what you should be doing is working on making the compiler a stand alone command line tool. Make it work without any of the editor/downloader/etc. Smile. just make it take source files and include paths and compile the code to a binary.
Then make a downloader tool (again command line) that will take a binary and send it to an attached P2. If you make those two things, then they can be used with literally any of hundreds of existing editors/IDEs.
Walk before run. PropellerTool will get Spin2 walking and running.
I'm getting multiple return values hashed out today for Spin2. This removes a constraint in programming that I suppose many of us have long since sublimated into our thinking.
Chip,
Since you didn't quote this part (above), I assume you missed it. This is the path to get Spin2 walking and running. This is the path that makes the most sense.
Yes, okay. I've been asked about this before. It's doable, of course. Just need to do it once things are running.
Do the Spin 2 compiler and the separate downloader, not already have command line versions ?
A program (as viewed in the object info window) of 4195 longs or less works fine when uploading to a propeller.
A program of 4196 or greater throws up a "Write Failure on COMx".
Other propeller programming tools don't have this problem with the CH340.
If memory serves, the SiLabs CP2102 exhibits the same behavior when used with Propeller Tool.
There have been several discussions about this over the years in the Prop 1 forum.
Chip, let me know where and to who's attn to send one of these prop plugs to. I'll have it in the mail tomorrow.
@"Dave Hein" already has quite a nice downloader in the form of the "loadp2" program. Why don't we use that? It's open source, portable (runs on Windows, Mac, and Linux) and tested in the field a lot already.
I'd certainly agree that a command line version of Chip's Spin2 compiler should be a priority.
Yes, and that is asked a lot about the PropTool, just give it some command line parameter to be called with as a start. Still is 86 assembler+Delphi and not portable, but One could call it from some other editor.
Better even let the Proptool call a external compiler and loader, so one could call fastspin instead of byte code from inside the proptool if wanted.
Make PropTool a IDE, separate compiler and loader from it. Spin2Gui (just typed Spin2Guy, what a Sigmund Freud thing) does this simple and nice, just put the same dialog options into the PropTool Menu.
All of us here have to accept that Chip wants his own code running his own P2, It is the 'I did all of it' mentality, and there is nothing wrong with that. Because he did and can be effing proud of himself, and he should be.
Changing PropTool to configure compiler and loader used externally, would combine this. Not hard for Chip to do, he has his way, we can use his compiler, Roy's compiler, Fastspin, whatever.
Does P2load currently support the WIFI loading option used by Blockly and the WX boards? If not this should be merged from the P1loader to make this available for future P2 boards.
Just reduce complexity and support problems by using the same tools on all platforms, fastspin uses p2load, Catalina seems to do, PropGcc seems to do and PropTool should also. Once support has that running they can check off - loader works, next step... independent if C, Basic, Spin, whatever is used. If it works for Spin it works for C, it works for Basic...
And if I would like to use Kolibri-Os as dev platform (I don't) I could compile the cmd-line-tools and be up and running, even with parallax support able to help me.
This just makes more sense as all integrated in PropTool and everything else uses different loaders.
Chip, please, separate byte-code-compiler, loader and OropTool into single executables with cmd-line parameters.
Enjoy!
Mike
-Phil
PropTool.2019 can do all of that, and it can include command line compilers and command line download.
A single closed binary-blob is very poor for software upgrades. (just look at the date on PropTool and the bug-list...)
The low effort, "it is up and running" part is a big win. P1 users can move immediately, low hassle.
All the other cool stuff being discussed can come, and it will be welcome.