I mean no disrespect to the plumbers of the world. They do a fine job and it can be hard work. Even if their estimating skills are about as bad as those of software engineers!
Back in the time when I was on the team testing the fly by wire software of the Boeing 777 we would fill out "PR" forms if we ever found what looked like a bug. Electronically of course, into some horrible old project management system's database. Every such bug report had a PR number. We generally referred to them as "Problem Reports". Until one day the powers that be severely reprimanded us for that. We could call them what we liked, "product report" or whatever, but we could not use the word "problem". Seemed to be some legal Smile covering going on.
I'm all for people forking and hacking on whatever code base they like. After all, that is what git was designed to make easy for the Linux kernel hackers. There are hundreds of Linux kernel forks. The trick is to get those changes eventually merged back to the upstream project. The road block here seems to be Parallax.
Unless, the user community flocks around some particular fork and forgets about the original upstream source. Is that likely? Is anyone really going to take on that task for the years ahead?
I mean no disrespect. In case you don't know, there's a small but significant group of programmers that call themselves the Linux Kernel Plumbers who even have annual conferences. When I first heard of them, I knew instinctively what it meant: Everyone with a compiler and a console can write Linux programs or even drivers, but all of that code wouldn't work if there wouldn't be a big bunch of software "plumbing" to tie everything together. And Mario is a plumber too... :-)
Yes, but that reduces the term to some niche in-house-joke, that does not transfer across languages/continents very well either.
Ideally, use something that google can find, using sensible/expected Prop repository search terms.
A new Engineering student is not going to guess to search 'plumbers' - it just makes the Prop look 'more weird'.
The Github home of Parallaxinc would potentially be a good candidate to become the Place To Be for the latest software. But it's apparently not being maintained very well either (if at all). And access is strictly read-only outside Parallax as far as I can tell (it's impossible to see who is in the Parallax organization unless you're part of it).
The conclusion is: There's a need to get organized.
...after more than five years of some very cool smart guys working at some very cool software, the only realistic choice is still to tell them they need to learn Spin and PASM, and use Propeller Tool under Windows.
I must be part of the problem. The synergy between Spin, PASM, and the Propeller architecture is everything! If one simply wants to learn C or develop an embedded application in C, why not use a $2 STM32F103 board? If one wants yet another Eclipse-like IDE, you're in luck: the world is full of them. The specific way color is used in PT adds significantly to orientation and enjoyment of the coding process, and is a wonderful break from Same-Old.
The one thing that does get traction with me is PropellerTool for Linux. I'd love to see a rewrite of PT in C or Python, and then added to Debian.
If one simply wants to learn C or develop an embedded application in C, why not use a $2 STM32F103 board?
That's an easy way to dismiss the problem. Blame it on the developer being stubborn if they don't want to do things your way and tell them to go away.
If one wants yet another Eclipse-like IDE, you're in luck: the world is full of them.
Development environments like Eclipse and Visual Studio make it possible nowadays to integrate your own features. It would be great to have a Spin/PASM compiler integrated in Eclipse or Visual Studio. Something like Visual Micro perhaps (an Arduino development plugin for Visual Studio, see http://www.visualmicro.com). That way Propeller development would be similar to Windows development or something.
But then you get pretty much the same problem as the one I quoted from you at the top: it's easier to program something if you already sort of know how it should work. And programming a plugin for Visual Studio or Eclipse is something that only few people can do. And learning how to do it is a significant investment in time, for which there is no reward except perhaps eternal fame.
So we ended up with a few new IDEs that are very promising, but inevitably just end up in a state where all the interesting work has been done, and the tedious work of adding small but important features, and fixing small but important bugs, takes over. And I totally understand how volunteers lose interest and move on to more interesting problems to solve.
But I don't even want to bitch about that (I understand it, I've been working on the same project for 15 years at my job; I would have quit 13 years ago if I would have had an easy alternative). The point of this thread is that users (i.e developers who use the tools) expect more when it comes to finding the tools in one place, and when it comes to regular bug fixes. And it's about how the developers of the tools can provide that "one place" since Parallax isn't doing it, with minimal effort.
Unfortunately we seem to be at a point where too many of the volunteers have already given up caring about those who would benefit from it. Or they don't trust me enough. It doesn't really matter.
That makes me pessimistic about the Propeller (1 and 2) ecosystem.
Integrating Spin/PASM into Visual Studio does not gain us anything. We already have a Windows solution in the Propeller Tool. Which is small and fast as opposed to the bloat and complexity of VS.
A Spin/PASM plugin for Visual Studio code would be neat. Then we get an open source and cross platform solution at least
Spin/PASM plugins for such things as Eclipse and IntelliJ might be nice for some. Cross platform at least. Personally I find them huge and annoyingly slow. Not to mention far too complex for beginners to install and use or for that quick hack.
There is a reason why the Arduino with it's drop dead simple IDE was a hit. The hope was PropellerIDE would be that for the Propeller.
Parallax moved to Propeller C because educators, their prime customers, had been demanding it for years.
Most of us were perfectly happy with Spin and PASM.
I actually find this 'us' and 'them' quite astonishing.
I think I belong to 'us' because I like SPIN and PASM. But I am also 'them' because I like to be able to run c on the propeller. Or Prop Basic, Or even Forth.
This 'all of us where happy with SPIN/PASM' is big BS. We where not.
SPIN/PASM is lacking a lot of stuff. Calling methods/procedures from other included objects for example (pointer to functions) or whatever you want to call it.
Support for external memory.
PropGCC does stuff like that SPIN/PASM does not.
But somehow there is this 'us' and 'them' between old fashioned SPIN/PASM and C/C++, completely unneeded.
I might be able to get COBOL running on a P2, am I now a 'it' in between 'us' and 'them'?
Parallax moved to Propeller C because educators, their prime customers, had been demanding it for years.
That is what I thought. Recently though I get the impression those educators have moved on the Blockly and Parallax's efforts are all going into that.
Most of "us" were happy with Spin/PASM, except for the fact that originally it was a Windows only solution. Luckily that is now fixed with OpenSpin, HomSpun, BST, etc.
Parallax moved to Propeller C because educators, their prime customers, had been demanding it for years.
That is what I thought. Recently though I get the impression those educators have moved on the Blockly and Parallax's efforts are all going into that.
Blockly (for other than the S2/S3 robots) is C without the syntax and ";" or "{}". It is simply a method for introducing beginners to programming logic so they can get things running w/o syntax debugging (although it is also interesting for prototyping slightly more advanced projects).
Once the students understand programming logic they can click on the "code" button and see the resulting C code. That can be exported to SimpleIDE where it can be modified directly.
I know Chrome books and other network restrictions at schools were causing all kinds of issues with SimpleIDE so I think Blocky was in part a solution to that plus its graphical nature is more intuitive for younger students.
Heater,
Back in the early 2000's I learned that Boeing C17 was using web-based applications although I know you are not a fan of Java.
Ah, so Blockly generates C or C++. I guess it had to generate something.
Personally I don't get the idea. Us kids were started with BASIC, which is notable for not having any complicated syntax to deal with and pretty damn easy for a beginner. Or it was so back in 1973. A few months later we were introduced to assembler.
I can't believe anyone was creating the safety critical control systems of the C17 with Java. That would be insane.
Ah, so Blockly generates C or C++. I guess it had to generate something.
Personally I don't get the idea. Us kids were started with BASIC, which is notable for not having any complicated syntax to deal with and pretty damn easy for a beginner. Or it was so back in 1973. A few months later we were introduced to assembler.
I learned programming in college (1967) using fortran and remember the joy of submitting the 8 inch thick punch card deck one AM and picking up the error printout the next AM, usually for some syntax goof (rinse & repeat).
In 1978 I bought a Compucolor 2 (8080A based all-in-one home disk based color computer) with an early version of MicroSoft Basic (plus CC2 graphics upgrades). Working with an interactive language was much more enjoyable. I did a lot of converting programs from Apple, Pet, and other Basics to the CC2 and then added some ASM patches. Since I didn't have those computers I had to figure out what some of there commands were doing and then figure to how to do it with the CC2. Interactively trying & running segments made it easy.
Unfortunately, it appears to be against the law (or some religion?) to teach programming with Basic. So we have young students using languages that are heavy on syntax which can lead to time wasting in an educational setting, and the student is expected to feel satisfaction when they finally get the {} to balance and an LED blinks. At least Blockly lets them make something more interesting in a reasonable time, and hopefully interests them enough to want to get more advanced.
I guess none of us became a genius. We're just recounting how we learned what a computer is and something about how to make them jump.
As for this threads problem, anyone is free to fork whatever open source project they like. The question then is, do they get developer community support behind them? Can this effort be fed back to Parallax? Are they up to the challenge of managing all of this for years into the future.
I don't know. Such efforts have worked out for projects like MariaDB, LibreOffice, node.js.
As for this threads problem, anyone is free to fork whatever open source project they like. The question then is, do they get developer community support behind them?
I'm beginning to wonder how big the developer community is these days. How many people are using PropGCC? I mean not including the ones who use it indirectly through BlocklyProp.
No, Java wasn't used to program the C17, production used the web for all their paperwork such as pulling drawings, recording the part and lot numbers used, etc.
I used BASIC on the Apple II and C64 and QBASIC on the PC.
I'm beginning to wonder how big the developer community is these days. How many people are using PropGCC? I mean not including the ones who use it indirectly through BlocklyProp.
Look at the amount of issues for propgcc and propeller-gcc...
For propgcc I didn't get an answer even after 7 months and propeller-gcc's issue 1 was raised years after the repository camt to life.
Looks like noone cares to raise issues and noone cares to answer.
As for this threads problem, anyone is free to fork whatever open source project they like. The question then is, do they get developer community support behind them?
I'm beginning to wonder how big the developer community is these days. How many people are using PropGCC? I mean not including the ones who use it indirectly through BlocklyProp.
Look at the amount of issues for propgcc and propeller-gcc...
For propgcc I didn't get an answer even after 7 months and propeller-gcc's issue 1 was raised years after the repository camt to life.
Looks like noone cares to raise issues and noone cares to answer.
Conclusion: C on the Propeller is dead.
(Hoping to get proven wrong now...)
As I've mentioned before, there were some bugs fixed that never made it into a SimpleIDE release. Also, funding for hiring people outside of Parallax to work on this has dried up. Anyone want to contribute on a volunteer basis?
Propeller C is not dead.
Parallax is concentrating on BlockyProp which is geared for their educational customers who are paying the bills.
It's simple economics and I am sure that as soon as the P2 is ready for release that the pendulum will swing back to product developers.
So C is essential for BlocklyProp but de facto unmainained?
How does that fit together?
The version of PropGCC that comes with SimpleIDE works for BlocklyProp. If there was a problem it would be fixed. So that version of PropGCC is being maintained as needed. It's just the later versions that have additional features not needed by BlocklyProp that are not being moved into production.
.... How many people are using PropGCC? I mean not including the ones who use it indirectly through BlocklyProp.
..but can you ignore those who might not know they are using it ?
Those are all PropGCC installs that do need to work.
I think the question is valid, in that attempts to ascertain how many people choose C over another language. Additionally, it would be interesting to know whether direct C usage has dropped off with the ascendency of Blockly.
Blockly is actually helping me get a handle on learning C. I get the basics out of Blockly, then open SimpleIDE and spend more time there modifying the code.
I think it was Phil who talked about how precious class time is so dealing with technical issues takes away from teaching time.
Indeed I did. When I taught Propeller C, an inordinate amount of time was spent helping students match unbalanced braces and deal with missing semicolons. And getting them to indent readably was a constant struggle.
Blockly is actually helping me get a handle on learning C. I get the basics out of Blockly, then open SimpleIDE and spend more time there modifying the code.
So PropGCC might progress as Blockly progresses?
Perhaps although I think BlocklyProp's requirements are minimal at least at present.
Comments
Back in the time when I was on the team testing the fly by wire software of the Boeing 777 we would fill out "PR" forms if we ever found what looked like a bug. Electronically of course, into some horrible old project management system's database. Every such bug report had a PR number. We generally referred to them as "Problem Reports". Until one day the powers that be severely reprimanded us for that. We could call them what we liked, "product report" or whatever, but we could not use the word "problem". Seemed to be some legal Smile covering going on.
I'm all for people forking and hacking on whatever code base they like. After all, that is what git was designed to make easy for the Linux kernel hackers. There are hundreds of Linux kernel forks. The trick is to get those changes eventually merged back to the upstream project. The road block here seems to be Parallax.
Unless, the user community flocks around some particular fork and forgets about the original upstream source. Is that likely? Is anyone really going to take on that task for the years ahead?
Yes, but that reduces the term to some niche in-house-joke, that does not transfer across languages/continents very well either.
Ideally, use something that google can find, using sensible/expected Prop repository search terms.
A new Engineering student is not going to guess to search 'plumbers' - it just makes the Prop look 'more weird'.
Yes, that bit everyone can agree with....
As an aside, for those studying downloaders, I came across this
https://github.com/grigorig/stcgal
Looks to be a Python PC code base, used to download to MCUs with a bootloader included. Interesting to see Python used there.
I must be part of the problem. The synergy between Spin, PASM, and the Propeller architecture is everything! If one simply wants to learn C or develop an embedded application in C, why not use a $2 STM32F103 board? If one wants yet another Eclipse-like IDE, you're in luck: the world is full of them. The specific way color is used in PT adds significantly to orientation and enjoyment of the coding process, and is a wonderful break from Same-Old.
The one thing that does get traction with me is PropellerTool for Linux. I'd love to see a rewrite of PT in C or Python, and then added to Debian.
Mind you I thought SimpleIDE was supposed to be that. Before it became ComplexIDE.
That's an easy way to dismiss the problem. Blame it on the developer being stubborn if they don't want to do things your way and tell them to go away.
Development environments like Eclipse and Visual Studio make it possible nowadays to integrate your own features. It would be great to have a Spin/PASM compiler integrated in Eclipse or Visual Studio. Something like Visual Micro perhaps (an Arduino development plugin for Visual Studio, see http://www.visualmicro.com). That way Propeller development would be similar to Windows development or something.
But then you get pretty much the same problem as the one I quoted from you at the top: it's easier to program something if you already sort of know how it should work. And programming a plugin for Visual Studio or Eclipse is something that only few people can do. And learning how to do it is a significant investment in time, for which there is no reward except perhaps eternal fame.
So we ended up with a few new IDEs that are very promising, but inevitably just end up in a state where all the interesting work has been done, and the tedious work of adding small but important features, and fixing small but important bugs, takes over. And I totally understand how volunteers lose interest and move on to more interesting problems to solve.
But I don't even want to bitch about that (I understand it, I've been working on the same project for 15 years at my job; I would have quit 13 years ago if I would have had an easy alternative). The point of this thread is that users (i.e developers who use the tools) expect more when it comes to finding the tools in one place, and when it comes to regular bug fixes. And it's about how the developers of the tools can provide that "one place" since Parallax isn't doing it, with minimal effort.
Unfortunately we seem to be at a point where too many of the volunteers have already given up caring about those who would benefit from it. Or they don't trust me enough. It doesn't really matter.
That makes me pessimistic about the Propeller (1 and 2) ecosystem.
===Jac
Integrating Spin/PASM into Visual Studio does not gain us anything. We already have a Windows solution in the Propeller Tool. Which is small and fast as opposed to the bloat and complexity of VS.
A Spin/PASM plugin for Visual Studio code would be neat. Then we get an open source and cross platform solution at least
Spin/PASM plugins for such things as Eclipse and IntelliJ might be nice for some. Cross platform at least. Personally I find them huge and annoyingly slow. Not to mention far too complex for beginners to install and use or for that quick hack.
There is a reason why the Arduino with it's drop dead simple IDE was a hit. The hope was PropellerIDE would be that for the Propeller.
Parallax moved to Propeller C because educators, their prime customers, had been demanding it for years.
Most of us were perfectly happy with Spin and PASM.
I think I belong to 'us' because I like SPIN and PASM. But I am also 'them' because I like to be able to run c on the propeller. Or Prop Basic, Or even Forth.
This 'all of us where happy with SPIN/PASM' is big BS. We where not.
SPIN/PASM is lacking a lot of stuff. Calling methods/procedures from other included objects for example (pointer to functions) or whatever you want to call it.
Support for external memory.
PropGCC does stuff like that SPIN/PASM does not.
But somehow there is this 'us' and 'them' between old fashioned SPIN/PASM and C/C++, completely unneeded.
I might be able to get COBOL running on a P2, am I now a 'it' in between 'us' and 'them'?
Confused,
Mike
Most of "us" were happy with Spin/PASM, except for the fact that originally it was a Windows only solution. Luckily that is now fixed with OpenSpin, HomSpun, BST, etc.
"We" also like C/C++
Blockly (for other than the S2/S3 robots) is C without the syntax and ";" or "{}". It is simply a method for introducing beginners to programming logic so they can get things running w/o syntax debugging (although it is also interesting for prototyping slightly more advanced projects).
Once the students understand programming logic they can click on the "code" button and see the resulting C code. That can be exported to SimpleIDE where it can be modified directly.
Tom
Heater,
Back in the early 2000's I learned that Boeing C17 was using web-based applications although I know you are not a fan of Java.
Personally I don't get the idea. Us kids were started with BASIC, which is notable for not having any complicated syntax to deal with and pretty damn easy for a beginner. Or it was so back in 1973. A few months later we were introduced to assembler.
I can't believe anyone was creating the safety critical control systems of the C17 with Java. That would be insane.
I learned programming in college (1967) using fortran and remember the joy of submitting the 8 inch thick punch card deck one AM and picking up the error printout the next AM, usually for some syntax goof (rinse & repeat).
In 1978 I bought a Compucolor 2 (8080A based all-in-one home disk based color computer) with an early version of MicroSoft Basic (plus CC2 graphics upgrades). Working with an interactive language was much more enjoyable. I did a lot of converting programs from Apple, Pet, and other Basics to the CC2 and then added some ASM patches. Since I didn't have those computers I had to figure out what some of there commands were doing and then figure to how to do it with the CC2. Interactively trying & running segments made it easy.
Unfortunately, it appears to be against the law (or some religion?) to teach programming with Basic. So we have young students using languages that are heavy on syntax which can lead to time wasting in an educational setting, and the student is expected to feel satisfaction when they finally get the {} to balance and an LED blinks. At least Blockly lets them make something more interesting in a reasonable time, and hopefully interests them enough to want to get more advanced.
Tom
How does solve the problem that was the reason for this thread?
As for this threads problem, anyone is free to fork whatever open source project they like. The question then is, do they get developer community support behind them? Can this effort be fed back to Parallax? Are they up to the challenge of managing all of this for years into the future.
I don't know. Such efforts have worked out for projects like MariaDB, LibreOffice, node.js.
No, Java wasn't used to program the C17, production used the web for all their paperwork such as pulling drawings, recording the part and lot numbers used, etc.
I used BASIC on the Apple II and C64 and QBASIC on the PC.
For propgcc I didn't get an answer even after 7 months and propeller-gcc's issue 1 was raised years after the repository camt to life.
Looks like noone cares to raise issues and noone cares to answer.
Conclusion: C on the Propeller is dead.
(Hoping to get proven wrong now...)
How does that fit together?
Propeller C is not dead.
Parallax is concentrating on BlockyProp which is geared for their educational customers who are paying the bills.
It's simple economics and I am sure that as soon as the P2 is ready for release that the pendulum will swing back to product developers.
Those are all PropGCC installs that do need to work.
-Phil
I think it was Phil who talked about how precious class time is so dealing with technical issues takes away from teaching time.
So PropGCC might progress as Blockly progresses?
-Phil