Cross language code use only works with fastspin of course. It can't be done with Chip's Spin2.
This is not an issue. Many of my Spin libraries were translated to C when C became available for the P1. If you or anyone else writes a great library in C that I want in Spin2, I will translate it -- I've done that with several Arduino libraries.
Cross language code use only works with fastspin of course. It can't be done with Chip's Spin2.
This is not an issue. Many of my Spin libraries were translated to C when C became available for the P1. If you or anyone else writes a great library in C that I want in Spin2, I will translate it -- I've done that with several Arduino libraries.
Because FlexC can run Spin2 objects (wow!) and the translation service JonnyMac offered (another wow!) it seems to me that the P2 ecosystem can grow the fastest if we grow the Spin2 library. This community really needs to rally behind that effort to get us to the starting line. MicroPython may very likely be able to leverage the Spin2 objects the same way done in FlexC.
For the last two hours I've been pouring over the ON/Parallax agreements, looking at our outstanding debt, wondering when Chip is going to start producing objects, and reading these forum threads -- all in consideration of placing a production order for the P2. Basically, I'm trying to build some confidence to move us to the next step but I need all of your help to get on board with the thought that we need to start producing functional, well-written objects. These can get wrapped into Eric's work, the P2 repository, and help this jet take flight again.
Real-time picture shown below. Help us allwin through Spin2 object development so I can place production order and I'll stop appearing in pictures and videos for a while as an added bonus. So far, we've got some useful objects from Ahle and JonnyMac. Soon, we'll announce their availability.
Ken Gracey
P.S. There's an awesome documentation effort underway by forum members Evan and Jon T, in particular!
Well, if C or better C++ was supported, you could simply use all these libraries.
I don't know that to be true given the hardware differences between the Propeller family and the hardware platforms supported in the Arduino ecosystem. And, personally, I just don't like C. I understand it enough to translate code, but I don't want to use it. Spin works for me.
If I'm wrong -- and I reserve the right to be wrong -- then people should be able to run Arduino libraries on the Propeller using FastSpin. Right?
What I really respect about people like Eric Smith and Peter Jackaki is that they unknowingly follow a rule by my mentor, Cliff Osmond: Don't suffer... solve! Don't whine... win! Both have seen and filled needs that Parallax -- for the moment -- doesn't have the resources to tackle. The community, and Parallax, benefits from their efforts. I may never write a client app in C or Forth, but I'm happy that those guys have given me the opportunity with the processor that I like best.
Okay, I confess. I may have been guilty of not following this rule. I'll try to do better in the future. I actually like programming in Spin (and likely in Spin2). I just wish they had structures or object pointers.
then people should be able to run Arduino libraries on the Propeller using FastSpin. Right?
I wish it were so, but no. Most Arduino code is actually C++, not C. FastSpin doesn't handle C++ for P2 (that I'm aware of... but I have been out of the loop for many months now)
Okay, I confess. I may have been guilty of not following this rule. I'll try to do better in the future. I actually like programming in Spin (and likely in Spin2). I just wish they had structures or object pointers.
Doesn't Spin2 have object pointers, or at least method pointers/delegates?
I'm really hopeful that something like GCC comes to P2 soon! But, I'm patient... After all, I'm a P2 fan... Been waiting a long time and it's finally here! (Now, just need the Redskins to win now...)
Spin is pretty nice for doing microcontroller type projects. But, with 512 kB, we can think about doing bigger things... Especially if you add in execution from HyperRam… And storage on eMMC...
Then, you will need C++.
Also, most code you can find to do complex stuff is in C/C++. It saves a lot of time to use it directly.
Python does add a twist though... It's still pretty popular (for reasons I don't personally understand).
I guess it's the new BASIC. Although, to be fair, it has powerful libraries that can do fancy stuff....
As a counter to all of that, one thing I like about Spin projects is that there is usually only a few files involved.
For some reason, C/C++ programmers seem to like subdividing projects into as many files as possible. To me, this kind of obfuscates what is going on...
fFor some reason, C/C++ programmers seem to like subdividing projects into as many files as possible. To me, this kind of obfuscates what is going on...
Helps weed out the weak from the strong. That's the only real reason.
As a counter to all of that, one thing I like about Spin projects is that there is usually only a few files involved.
For some reason, C/C++ programmers seem to like subdividing projects into as many files as possible.
There's typically several reasons for this apparent madness.
1) splitting a project allows code re-use, eg. a common C++ class or a C module can be used in other projects
2) these languages need header files for function prototypes/class declarations - that itself can automatically double the number of files needed.
3) modular development allows different teams to work on different file modules simultaneously without lots of extra merging of shared files needed during changes because everyone is editing the same file
4) manages file editing, as huge monolithic files with everything in it becomes tedious to navigate/edit once they grow to many thousands of lines
5) C/C++ is often used for larger projects compared to SPIN. There's just more total code in some of these projects.
To me, this kind of obfuscates what is going on...
It can if split poorly. At the start of any project there is typically lots of mental investment required to understand where various things come from in the code base and all projects differ, there is no standard way to define things. If the files and modules were layed out in a good structured way by the original developer this is not as bad as if they are split arbitrarily. However I have worked on huge C++ team projects with enormous numbers of template classes and understand the obfuscation when the debugger throws up random runtime objects you have to try to track down in the source code each time. Totally hated that.
C(++) code turning into a mess is inevitable. Navigating large projects without IDE support is just not a good time. Languages like Java and, indeed, Spin, make it obvious in which file a method is defined and many others (most languages with untyped functions (also including Spin...)) make it easy to do a text search for a function definition. C does none of this.
Slightly related:
I haven't got to use it yet, but I've heard great things about Rust. It's apparently a lot like C++, except with 35 years of hindsight. No headers. Well-defined integer types. Range-checking by default. Standard method for packaging and installing libraries.
Really seems like something to look into.
I like C on embedded cpu very much bit let’s face it:
P2 needs to make money
Chip loves his spin
Parallax is a small company with restricted resources
C code expands very fast due to the big libraries that make C so sexy
C++ is a huge thing with all its runtime type information, exception handling and dynamic memory model
I do not like spin myself, but I tie the challenge and learn. It i find any problem I tell chip and he will work on it.
Fastspin is my way I will go and I already be a Patreon for
Fastspin can consume objects from obex so I’m happy
Slightly related:
I haven't got to use it yet, but I've heard great things about Rust.
It's apparently a lot like C++, except with 35 years of hindsight. No headers. Well-defined integer types. Range-checking by default. Standard method for packaging and installing libraries.
Really seems like something to look into.
Seems to have an embedded-friendly type range choice, including a native boolean.
* signed integers: i8, i16, i32, i64, i128 and isize (pointer size)
* unsigned integers: u8, u16, u32, u64, u128 and usize (pointer size)
* floating point: f32, f64
* char Unicode scalar values like 'a', 'α' and '∞' (4 bytes each)
* bool either true or false
If you like rust you will love c#
MS is working on nativ c# to assembler Compiler so you can skip the compile on first rum step that makes c# startup always a little bit slow
C# (actually the .net type system) offers the best type system I have ever seen.
I have written compilers for cobol, pl1, mumps, Java, c#, c and even c++ for my living so I had to understand the deep burried things all this languages use, and c# has astonished me the most
C# and is noting like c or java at all, its more like a successor to rust
If you like rust you will love c#
MS is working on nativ c# to assembler Compiler so you can skip the compile on first rum step that makes c# startup always a little bit slow
Interesting. Is that C# to WebAssembly ?
That brings up a key point of P2 compilers like ersmith's : They support very clean in-line P2 assembler.
Comments
Because FlexC can run Spin2 objects (wow!) and the translation service JonnyMac offered (another wow!) it seems to me that the P2 ecosystem can grow the fastest if we grow the Spin2 library. This community really needs to rally behind that effort to get us to the starting line. MicroPython may very likely be able to leverage the Spin2 objects the same way done in FlexC.
For the last two hours I've been pouring over the ON/Parallax agreements, looking at our outstanding debt, wondering when Chip is going to start producing objects, and reading these forum threads -- all in consideration of placing a production order for the P2. Basically, I'm trying to build some confidence to move us to the next step but I need all of your help to get on board with the thought that we need to start producing functional, well-written objects. These can get wrapped into Eric's work, the P2 repository, and help this jet take flight again.
Real-time picture shown below. Help us all win through Spin2 object development so I can place production order and I'll stop appearing in pictures and videos for a while as an added bonus. So far, we've got some useful objects from Ahle and JonnyMac. Soon, we'll announce their availability.
Ken Gracey
P.S. There's an awesome documentation effort underway by forum members Evan and Jon T, in particular!
If I'm wrong -- and I reserve the right to be wrong -- then people should be able to run Arduino libraries on the Propeller using FastSpin. Right?
What I really respect about people like Eric Smith and Peter Jackaki is that they unknowingly follow a rule by my mentor, Cliff Osmond: Don't suffer... solve! Don't whine... win! Both have seen and filled needs that Parallax -- for the moment -- doesn't have the resources to tackle. The community, and Parallax, benefits from their efforts. I may never write a client app in C or Forth, but I'm happy that those guys have given me the opportunity with the processor that I like best.
I wish it were so, but no. Most Arduino code is actually C++, not C. FastSpin doesn't handle C++ for P2 (that I'm aware of... but I have been out of the loop for many months now)
Spin is pretty nice for doing microcontroller type projects. But, with 512 kB, we can think about doing bigger things... Especially if you add in execution from HyperRam… And storage on eMMC...
Then, you will need C++.
Also, most code you can find to do complex stuff is in C/C++. It saves a lot of time to use it directly.
Python does add a twist though... It's still pretty popular (for reasons I don't personally understand).
I guess it's the new BASIC. Although, to be fair, it has powerful libraries that can do fancy stuff....
As a counter to all of that, one thing I like about Spin projects is that there is usually only a few files involved.
For some reason, C/C++ programmers seem to like subdividing projects into as many files as possible. To me, this kind of obfuscates what is going on...
Helps weed out the weak from the strong. That's the only real reason.
There's typically several reasons for this apparent madness.
1) splitting a project allows code re-use, eg. a common C++ class or a C module can be used in other projects
2) these languages need header files for function prototypes/class declarations - that itself can automatically double the number of files needed.
3) modular development allows different teams to work on different file modules simultaneously without lots of extra merging of shared files needed during changes because everyone is editing the same file
4) manages file editing, as huge monolithic files with everything in it becomes tedious to navigate/edit once they grow to many thousands of lines
5) C/C++ is often used for larger projects compared to SPIN. There's just more total code in some of these projects.
It can if split poorly. At the start of any project there is typically lots of mental investment required to understand where various things come from in the code base and all projects differ, there is no standard way to define things. If the files and modules were layed out in a good structured way by the original developer this is not as bad as if they are split arbitrarily. However I have worked on huge C++ team projects with enormous numbers of template classes and understand the obfuscation when the debugger throws up random runtime objects you have to try to track down in the source code each time. Totally hated that.
Slightly related:
I haven't got to use it yet, but I've heard great things about Rust. It's apparently a lot like C++, except with 35 years of hindsight. No headers. Well-defined integer types. Range-checking by default. Standard method for packaging and installing libraries.
Really seems like something to look into.
P2 needs to make money
Chip loves his spin
Parallax is a small company with restricted resources
C code expands very fast due to the big libraries that make C so sexy
C++ is a huge thing with all its runtime type information, exception handling and dynamic memory model
I do not like spin myself, but I tie the challenge and learn. It i find any problem I tell chip and he will work on it.
Fastspin is my way I will go and I already be a Patreon for
Fastspin can consume objects from obex so I’m happy
Yes, looks interesting, Google finds this.
https://doc.rust-lang.org/rust-by-example/primitives.html
Seems to have an embedded-friendly type range choice, including a native boolean.
* signed integers: i8, i16, i32, i64, i128 and isize (pointer size)
* unsigned integers: u8, u16, u32, u64, u128 and usize (pointer size)
* floating point: f32, f64
* char Unicode scalar values like 'a', 'α' and '∞' (4 bytes each)
* bool either true or false
It's not clear if f64 is optional ?
MS is working on nativ c# to assembler Compiler so you can skip the compile on first rum step that makes c# startup always a little bit slow
C# (actually the .net type system) offers the best type system I have ever seen.
I have written compilers for cobol, pl1, mumps, Java, c#, c and even c++ for my living so I had to understand the deep burried things all this languages use, and c# has astonished me the most
C# and is noting like c or java at all, its more like a successor to rust
That brings up a key point of P2 compilers like ersmith's : They support very clean in-line P2 assembler.