Open Letter to Jeff Martin
Phil Pilgrim (PhiPi)
Posts: 23,514
31 October 2010
Dear Jeff,
Duly-anointed "Chief of Crankiness" here, and I'm afraid I've got some bones to pick. So please bear with me.
The Propeller Tool is nice as far as it goes, but it doesn't go nearly far enough. For four and a half years, user requests for significant feature enhancements have been ignored, and third-party tools like BST have left the Propeller Tool in the dust. (I wish I could use BST, but I can't, since much of my programming is for projects sanctioned by Parallax.) To be fair, you've always provided prompt service for minor bug fixes and command-line enhancements, for which I'm very grateful; but it's long past time to tackle more than just the low-hanging fruit.
For example, my Propeller source folder now sports more than 600 Spin files and no way to organize them, because OBJ specifications do not allow subdirectory references. I have pleaded and cajoled for this feature to be added for several years now, to no avail.
Also, a bug that's particularly irksome -- still, months after your acknowledgement of it -- happens when I use shift-down-arrow to select lines to indent (or unindent). When hitting TAB, it always adds the following line to the action to be performed. (The BASIC Stamp Editor handles this situation correctly, BTW.)
And what about macros, #include files, preprocessor hooks, and all those other niceties expected from professional-grade development tools? Despite numerous user requests over the years, they're still absent.
Notwithstanding the availability of great third-party tools like BST, the Parallax Propeller IDE absolutely must be the Gold Standard for Spin and PASM development. This is necessary not only as a common denominator for the OBEX, but also to attract serious customers to the Propeller chip itself. But, so far, the IDE has met little more than the minimum requirements for a development tool. And it's time for that to change.
I don't know what you're working on right now; but I assure you, it can't be more important than tackling the issues I've pointed out. Parallax's very life as a semicondcutor supplier depends on it -- and so do we, the Propeller users, integrators, and system designers. So, please, step up to the plate, bat one out of the park for us, and give us a professional-level IDE to cheer about! And please don't wait for the Prop II to come along. We need it now.
Thanks for listening.
Respectfully,
Phil Pilgrim
Bueno Systems, Inc.
Dear Jeff,
Duly-anointed "Chief of Crankiness" here, and I'm afraid I've got some bones to pick. So please bear with me.
The Propeller Tool is nice as far as it goes, but it doesn't go nearly far enough. For four and a half years, user requests for significant feature enhancements have been ignored, and third-party tools like BST have left the Propeller Tool in the dust. (I wish I could use BST, but I can't, since much of my programming is for projects sanctioned by Parallax.) To be fair, you've always provided prompt service for minor bug fixes and command-line enhancements, for which I'm very grateful; but it's long past time to tackle more than just the low-hanging fruit.
For example, my Propeller source folder now sports more than 600 Spin files and no way to organize them, because OBJ specifications do not allow subdirectory references. I have pleaded and cajoled for this feature to be added for several years now, to no avail.
Also, a bug that's particularly irksome -- still, months after your acknowledgement of it -- happens when I use shift-down-arrow to select lines to indent (or unindent). When hitting TAB, it always adds the following line to the action to be performed. (The BASIC Stamp Editor handles this situation correctly, BTW.)
And what about macros, #include files, preprocessor hooks, and all those other niceties expected from professional-grade development tools? Despite numerous user requests over the years, they're still absent.
Notwithstanding the availability of great third-party tools like BST, the Parallax Propeller IDE absolutely must be the Gold Standard for Spin and PASM development. This is necessary not only as a common denominator for the OBEX, but also to attract serious customers to the Propeller chip itself. But, so far, the IDE has met little more than the minimum requirements for a development tool. And it's time for that to change.
I don't know what you're working on right now; but I assure you, it can't be more important than tackling the issues I've pointed out. Parallax's very life as a semicondcutor supplier depends on it -- and so do we, the Propeller users, integrators, and system designers. So, please, step up to the plate, bat one out of the park for us, and give us a professional-level IDE to cheer about! And please don't wait for the Prop II to come along. We need it now.
Thanks for listening.
Respectfully,
Phil Pilgrim
Bueno Systems, Inc.
Comments
The last page of the thread is located at http://forums.parallax.com/showthread.php?t=121707&page=14 .
Dave
Al
With respect to pre-compiler "niceties", an "#ifdef# really is needed more and more. There are a number of reasons to use this, but there is one single item that makes it virtually mandatory in the current environment, and that is by Parallax's making. The overriding reason in the Propeller Serial Terminal, or PST.
This is one of the "de-facto" debugging tools, and per none other than Ken Gracey, the preferred (and/or necessary) method of providing "demos" for the object exchange. See This Post in This Thread
So, what is one to do when the final product will not have access to sending back data (or getting input from) the PST? In some cases, you can leave the code it place. In others you HAVE to either carve it out or comment it out. Why do we have to do this? Why, in order to debug, do we need to add lines of code, then either remove or comment them for production (and potentially add/uncomment again later)?
If we could simply do the following in the top object file:
#define DEBUG
or
#undefine DEBUG
Then we could surround PST Code (including the inclusion of the PST Object) with
#ifdefine DEBUG
... PST code here
#endif
Why can't we have this?
John R.
Ray
John R.
However, I just want to bring to mind the changes that will be needed for P II is something they may be waiting for before committing to changes in the Propeller tool.
Just an opinion here.
One other thought that popped to mind is that there has been discussion of taking the IDEs "Open Source", but due to the development environment being used, there was a lot of work to do. (Libraries, and other component licensing, etc.) That may be what's happening...
John R.
-Phil
Why is that? bst is bit for bit compatible with the Parallax tools and unless you enable the "Non-Parallax extensions" in the IDE preferences it should have the same limits as the Parallax IDE does.
-Phil
It's time for some comment! We all can see the merit of the suggestions, the need for a few fixes, and for the most part believe Parallax must have the Gold Box version of the PDT. What's missing in this thread is a comment from Parallax about what's happening. Most any comment to establish what we can expect.
Fred
I could make PropBasic LMM jumps faster if it did.
Bean
I feel sorry for Phil that he can't use BST as that is what I use and just can't be bothered with the Spin play tool. In comparing the two main Prop tools if I didn't know who did what I would say that the Prop tool was the "community version" and BST the professional version.
But I agree with Phil when he says that at least from Parallax's point of view that their tools should be the gold standard or else what are they going to tell their big interested customers when their jaws drop in shock and horror at finding the state of the tools at such a rudimentary level.
Sure, Spin tool was fine for when it was first released, more like a beta version, but that hasn't really improved much in all these years. I have suggested it before that perhaps Parallax should enter into an arrangement with BradC who seems to know what he is doing (and is willing to do it).
Parallax! where is your reply? Even an acknowledgement? Peek from behind the curtain maybe?
Yeah, sorry about the lack of responsiveness lately. I've been battling some other issues (both work and personal) and something had to give. I haven't even fired bst up in months now and my Propellers sit idle on the shelf. On the other hand, I've just acquired my first lathe so I hope to get some more diy motivation happening some time soon.
I just wanted to chime in and state that probably most of the "enhancements" in the bst compiler were done first by Michael Park in homespun. I can't really claim any of them as my own and don't wish to do so.
I apologize for the late delay in our response. In fact, I told Jeff that I'd reply to this thread several days ago. The late delay is all my fault, not Jeff's [he's the nicest guy on the planet - I'd hate to see him in trouble when it's my fault]. The reason I'm replying is because we are trying to focus our engineering and R&D efforts by focusing their attention.
Jeff Martin handles our internal software projects, often alone. In the last year we've posted positions and made contacts with external developers to increase the size of our software team, but it hasn't been too productive. Part of the problem is that we've been using Delphi for many years - apparently it's not easy to find Delphi developers.
For future projects we're looking at Lazarus. This is a long-time, open-source development project to make a multi-platform tool based on the FreePascal compiler (essentially Object Pascal, like Delphi). It's not available as v 1.0 yet. I think Brad may have used it for BST.
To your points:
OBJ specifications to allow sub-directory references We have this working on an internal software revision. Even a rookie hobbyist like me knows the importance of this, having revised and replicated most of the objects I use and trying to track them each time I have a project. What's not completed is the graphical interface to support this improvement. That comes next.
Shift-down-arrow bug This bug is noted and in the queue. The next Prop Tool release probably won't fix this at the same time depending on the extent of bug-hunting and bug extermination.
Macros, include files, pre-processor hooks Noted and in the queue, but won't happen as quickly as the first request you've made. However, depending on how this feature is developed we also need it inside of Parallax for our Propeller C Translator (more below). We agree with everything you pointed out about how it would benefit other developers (PropBASIC, C compilers, etc.) as well.
You mentioned that whatever Jeff is working on, it can't possibly be more important than the items you identified above. I can address your point by telling you why these requests can't be handled immediately.
Jeff's experience is required to close up the WiFi project. Parallax has $150-200K of development costs in that product and we expect to recover them through hardware sales. It will take about three weeks of his time and he's already into the project, known internally as the Parallax WiFi Configurator. The WiFi Configurator is a necessary software tool to help customers set up our WiFi module for wireless programming of Propellers/BASIC Stamps from their PC. This tool does things like identifies wireless access points, provides a place for MAC address, etc. The WiFi hardware is in the final stages of development and we're on target for our last prototypes at the end of this month. Sideways for a moment - you will be happy to know that we are writing the WiFi Configurator in C using CodeBlocks with WXWidgets. If we can't compile it for Mac and Linux then I'm sure somebody else on this forum can do it for us. (LQQK - no Delphi required!).
Although the WiFi Configurator may not be important as the improvements to the Propeller Tool from some perspectives, it's a short-term delay for another long-term need that is very important to a tremendous bulk of the Parallax customer base: educational and hobbyists who program our products in schools and universities.
We agree that a semiconductor supplier should have more professional tools. Adding a software engineer to our staff is the top priority now (this week we added IT2, the code name for "IT Guy #2" AKA Dan McGlade). The addition of IT2 lets us address some of the other requests in the Suggestions forum. There's a lot shaping up behind the scenes right now and the future for the Propeller and Prop Tool is very positive.
The other important project for Jeff is a C Translator. Our Education team and customers have a serious need for a C to Spin translator. I don't want to get into how everybody feels about the necessity of C for the Propeller in this thread, but we're going to give the educational customer what they have requested (specifications were floated six months ago on the Propeller forum). The C Translator would likely need the same pre-processor hooks that you requested. This is Jeff's next project after the WiFi Configurator. And yes, this project will take a long time, so we will expand our software engineering team to manage the Prop Tool requests concurrently.
The WiFi Configurator and C Translator are fast-tracked projects.
This may not be the level of detail you were looking for in a reply. Feel free to tell us where you want more detail.
Ken Gracey
Parallax Inc.
Thanks for the reply. And, no, I did not find it lacking in detail at all, which I do appreciate!
It would appear that Parallax's dev team is in a constant state of triage, which I can fully understand. What this means, though, is that small fires get doused, while the bigger, more complicated infernos are left to burn. So, as a (rather demanding) user, it probably behooves me to make a big fire look like a little one, rather than raising five alarms in the forum.
To that end, here are a couple proposals to consider:
1. Finish work making the OBJ block subdirectory aware. My other suggestions could easily be addressed by outside sources if only we had the necessary hooks to write our own preprocessors. It would work like this: In the Spin program there would be a DEV block with a precompiler directive that specifies a standalone program or batch file. (This syntax apparently already exists, but is not active.) This file would accept the source code from the current object via STDIN, produce compilable Spin code, and deliver it via STDOUT. Precompiler errors could be reported via STDERR, so that the IDE could flag them in the source. This would make things like #INCLUDE files, conditional compilation (which I negelected to include in my list), and macros easy to accommodate via the preprocessor.
2. If the OBJ block subdirectory stuff turns into too big of a fire, it could still be accommodated via preprocessing, but the preprocessor becomes a little more complicated. Rather than returning unvarnished Spin source code, it would have to return a fully-qualified path to a top object file and all of its preprocessed sub-objects in a temporary directory. IOW, the onus would be on the preprocessor writer to locate the sub-objects, based on the same subdirectory references referred to above.
In either event, whether it's part of the IDE, or performed by a preprocessor, locating the various sub-objects needs to be based on two things:
a) The user's PATH variable, which tells the sytem where, and in which order, to search the user's computer for files, and
b) relative subdirectory references in the OBJ block, which tells the compiler/preprocessor where to retrieve each object.
Also, in case 1. above, the IDE would need to include any preprocessor(s) in any archive it produces. In case 2., the user would have to provide his own archiver, which could be specified in the DEV section with an archiver directive, which I believe is also currently in Spin's syntax.
So, does this reduce the flames enough to make it a top priority?
Looking much further forward, I hope Chip and Jeff will solicit user input for the Prop 2's IDE and compiler, much as Chip has done for the hardware. I think it would help to avoid some of the shortcomings of the current tool from the get-go, when they're easier to deal with.
Thanks much for your attention to these matters, Ken, and for coordinating the "fire dispatch". Hopefully, I've been able to outline some compromise priorities that not only solve the immediate problems but are considered doable in the short term.
-Phil
So, please correct me if I'm wrong, but over a year later, and still nothing really new here? I just can't believe the lack of attention from Parallax to their main development tool. It's the first thing a new (or potential) customer is going to see when evaluating the Propeller, and it lacks many, many of the professional features available in pretty much every tool I've ever used to develop for other companies' products. How can this be? Is there something better out there that is officially supported by this point?
In the meantime, I think I will start using BST. It looks great, for the most part, except I really miss a few things that the Prop Tool DOES have (wish I could just merge the two together!), such as:
-the lines that clearly indicate what is indented inside of what
-bookmarks
-more capable "Compile Info" view...in the Prop Tool's version, you can click on child objects to see their individual memory usage
-the condensed, summary, and documentation views (not really that big a deal, except for supporting everything from the Prop Tool...and I actually do like the Documentation view when code is written in a way to use it properly)
<EDIT> - As long as I'm including things that BST lacks, I really should mention viewing different objects at the same time in different windows...in fact, I use that so much, I'm trying to decide if that now tips me back in favor of the old Prop tool again now that I noticed BST can't do it! Speaking of multiple views, I'm also rather disappointed that even the Prop Tool won't let me have a split view of 2 different parts of the same file.
--Oh, and BST lacks the "align" cursor mode from the Prop Tool, which I actually got quite used to using. I think I'll try editing code in the Prop Tool and switching to BST for compiling, but that has its own annoyances.</EDIT>
But overall, BST includes way more important things that Prop Tool lacks than the other way around. I'm just going to have to start using bigger tabs inside IFs, loops, and things so my indentations are more obvious.
But I would still love to see a real, full-fledged IDE. It's shocking to me that this doesn't seem more important to Parallax than it apparently is.