Propeller Tool Future Possibilities
System
Posts: 45
in Propeller 2
This discussion was created from comments split from: Spin Tools IDE.
Comments
With Parallax announcing the end of development of Propeller Tool, there is an opportunity for Spin Tools IDE to be the go-to for those of use who enjoy the look and feel of Propeller Tool. I'm tossing out these ideas which would make ST perfect for me, and I hope others will chime in, too -- I'm sure I'm missing something.
Add custom library path(s) to File/Open From... flyout menu
Add "Identify Hardware" to Tools menu
Add PT-like hot keys to menus
Add tool buttons to match most-used menu items
Allow user to modify rules for Format Source (I prefer 2 spaces in Spin)
Allow user to modify syntax highlighting and terminal colors
Allow "View Character Chart" (as in Propeller Tool) if Parallax font selected for Editor
Long-term, I hope Spin Tools IDE will support the programmer's choice of compiler (internal, PNut P2, PNut P1, FlexProp, etc). This is where F9 Compile comes in.
Thank you for your efforts on this project, Marco.
Wait, what? Parallax is discontinuing the Propeller Tool? When did they announce that? And what are they replacing it with?
Not an announcement per-se, just a mention on live forum that it may be discontinued in the future since it needs a lot of maintenance and as previously exposited, can not be made open-source/cross-platform. The current idea is to replace the editing tools with the VSCode extension. The compiler may be re-created in TypeScript eventually, too.
I think they should be a bit more specific.
There is a big difference between development being discontinued, meaning no longer developed and discontinuation of the tool, meaning end of life (you use what you have until it breaks, no support, no nothing afterwards).
Which is it then ?
The Windows-only Propeller Tool will not get any further development. PNut, which is written by Chip, will continue and can be used as-is, or as a CL tool with an external editor, e.g., with VSC as some do now. Long term, the PNut compiler will be made x-platform. ATM, Chip is suggesting TypeScript. I don't know if that's the best language for an x-platform compiler, so those that have an opinion should chime in with Parallax.
There are editor choices. I happen to like Propeller Tool and would love it with a few niceties. Knowing that's never going to happen I am grateful to Marco because he has been very responsive to user suggestions (block copy-paste is not quite as nice as in PT, but it's close and all the other features make up for that). The push now is on Parallax to stop single-platform development of software tools and move to an approach that will allow P1 and P2 compilation on any platform.
It's a decent option. VSC uses TypeScript for extensions, so it would be easy to have real-time compilation (like SpinTools has).
Building JS/TS as a standalone application is somewhat eh, either good speed with massive bloat or small executable with slow execution.
Chip hates that, which is why he still writes the Propeller compilers in x86. He wants small and fast. Am I missing something or would C or C++ be a better choice a CL compiler that can be compiled to work on Windows, Linux, and Mac? What does Eric use for FlexProp? I wonder what Marco is using inside Spin Tools.
C is certainly a good choice, if the source doesn't have platform-specific code (as I believe a compiler should not have), it can be compiled for any platform and reused in third-party products with the appropriate bindings (Java for example can link to external libraries with native code, other languages may provide similar interfaces).
The core FlexProp is C while the UI is TCL/TK if I'm not wrong.
Spin Tools is entirely Java, compiler included, with native libraries for UI (Eclipse SWT) and serial interface.
No, you're not missing anything.
FlexSpin is C, SpinTools is Java.
I wouldn't recommend either for a new project. C is an infinite well of tedium and strange bugs and Java has a bloat problem (esp. if you bundle your own runtime, but not as bad as node.js etc) and is kindof a dog to call into from other environments. C++ is C minus some of the tedium (hooray for
std::vector!!!! (and awkward silence forstd::unordered_map...). There isn't much reason to use C over C++, except that C++ lets you make awful messes in a way C doesn't. I haven't used it much, but the current hype is Rust, which is basically C++ but with strict rules that stop most of the aforementioned C/C++ bugs dead in their tracks (but they also get in your way...).Also, this is off-topic, @VonSzarvas please split. --> Kapow ... Done! <--
It'd be nice if they could open source the part of the Prop Tool code that does the "Block Group Indicators".
Does @macca 's code have those? It tried to implement with my own spin/spin2 editor, but couldn't get that right...
Ok, just saw a post saying @macca 's code does the indents (always correctly?)
BTW: Sorry to hear about PropTool being deprecated, but guess lucky they were able to make it work with Spin2 as it is now.
VS Code plugin sounds good. Wish they could also do a plugin for regular VS...
Yes. The lines are a little thin, but I suspect that's an easy fix.
I've done a bit of testing and haven't noticed any problems. I don't know with certainty, but I think Marco is converting tabs to spaces, especially since Spin Tool has smart tabs by section like Propeller Tool.
I'm sad that Propeller Tool is ending development before it was really finished, but this may give Parallax the real boost it needs to make the official compiler x-platform. I would also love to see the P1 compiler treated the same way, and, perhaps, even updated a bit to be more compatible with Spin2 standards (that would have to be optional so old code doesn't break).
From Spin Tools.
Been a while but I think the issues I had where when the indents became 5 or 6 levels deep..
Remember OpenSpin exists already? Flexspin's P1 bytecode mode is superior though (because I made it, duh) and the Spin frontend does accept a number of Spin2-isms in Spin1 mode. Try it, it might just satiate your needs.
No. I am not satisfied that non-Parallax compilers are worth risking my customer projects. I may change my mind, but it won't be any time soon.
I don't like the "hype" in this job. Today is Rust, yesterday was "don't know what", tomorrow another esoteric language that promises to solve all programming issues but doesn't solve anything (except some ghosts in the developer's own mind) because bad code can be written in any language.
The right tool for the job instead: if I have to write a library that may be used by others, I'll write it in C. A dynamy link library can be easily imported in (almost) any language on any platform with simple wrappers. Can't say so for other, more "modern" languages, unless importing all the bloat needed by that language, or use as a command line-only tool (which still requires all the bloat).
Other kind of applications have more or less suitable languages, mostly what the developer is more proficent with (myself, I'll write everything in Java for that matter...), with the hope to find other developers familiar with that language in the case the original developer goes away for a reason or the other (this may be very important for "official tools").
...
You tell me:
Try yourself, if there are cases where the indent lines are not drawn correctly, I'll fix it.
As far sa I know, the Propeller Tool/Pnut are written in Delphi (?)
If yes, why not move to Lazarus? It is multiplatform and its programming language is near 100% Delphi compatible. It produces native code for PC - Windows and Linux, Mac and even RPi... or Amiga.
The x86 assembly code should be rewritten to allow the tool to run on non-x86 based machines.
Lazarus has a code editor component that may be customized for any programming language. Compiler can be configured and called as an external program, so such a tool may be used for any P2 compiler available... I know about at least 4 of them...
Spin is ok for many purposes, but C is ... well ... just necessary if the Propeller wants to be taken seriously.
Yes, it is. All the people that I tell about a P2 ask me if it can be programmed in C. The good news is - it can. We have at least 2 C compilers available. - FlexC and Catalina. Maybe more.
That's just not true. The language does have an effect on the average quality of the code written in it. In C you have fifty guns pointed on your feet at all times (see: any std function involving strings, type confusion (what size is a
longagain? extra fun with int promotions on platforms whereintis not 32 bit), struct layouts not actually being consistent between compilers, no pre-supplied data structures, no way to ensure resources aren't leaked, etc, etc, etc). Almost like we learned from our mistakes in the past 50 years. Though I don't think there's a 100% replacement for C specifically yet that's actually good (except C++ of course). There really should be though.You could obviously use C++ here instead, for what that gets you (might need to set some flag to static libc++ if you need it). Rust can also build dynamic or static libraries that conform to C ABI. All the lower-level languages can do it. The only exception is on platforms that actually only have a regular C compiler, which is getting really rare (even on P2 we technically have p2gcc and the LLVM port, though neither is used much AFAICT).
Mind that I mostly use either C++ (for performance), Java (for GUI) or Ruby (everything else) for my own tool development. The former two are really obnoxious in terms of the language itself, but I have experience with them and they have the tooling to do what I need them to, whereas Ruby is a mostly nice language, but dog-slow (similar to Python) and lacking a really good GUI library. For the kind of tooling I often write, the time saved using a more comfortable language outweighs the CPU time wasted when running the tool.
Sorry that this thread went off the tracks, @macca. I do like Spin Tools very much, and hope that you'll consider the feature requests I outlined above, including the ability to work with an external compiler (even if that means not having some of the niceties that your internal compiler offers). Thanks, again, for your efforts on this project.
No problem, your list is on my todo list, including the external compilers support.
Just downloaded Spin Tools IDE...
Looks good.
Also, passes the block group indicators test that my SpinEdit failed...
Thank you! Grazie!
As they say here in Hollywood during awards season... for your consideration.
Comment/Uncomment selected lines. Add to Edit menu, right above Format Source. Use hot-key Alt+' or Ctrl+'.
Logic: If first character in line is not an apostrophe, insert apostrophe at front of line, otherwise if first character of line is apostrophe, delete first character.
Using the line approach versus curly braces allows a block to be commented out, and then portions selectively uncommented. I guess a corner case as a selection that has some lines commented while others aren't. Following the simple rules would toggle the comments -- which might be useful in testing.
Thanks for considering.