1) Whilst having feature parity with the old Prop Tool is desirable I see no reason to carry miss-features forward into the modern world. They are a shackle that inconveniences everyone and wastes development effort that could be better used elsewhere.
2) Using UTF-16 in the modern world is just dumb. Everyone realized the problems with that a long time ago and UTF-8 is the result. Clearly a Prop Tool replacement should use UTF-8
(Aside: Being an older guy I think moving away from ASCII is a big mistake )
3) Putting schematics into source code as ASCII art is a bad idea. Changing from ASCII to UTF16 is even worse. Having to use a particular font to make that work is even worse. This has to go for the sake of every ones sanity.
4) Having my code editing experience be dependent on a custom font is just silly.
5) Creating an editor/IDE that is required to support all that cruft is a pain. For example a WEB IDE like msrobots Editor17
Somebody mentioned adding the ability to include schematics as images in the source code. Nice idea but now the IDE has to understand a ton of image formats, PNG, GIF, JPG, etc or even the source code of those images, svg, scm, whatever. Binary images are bad news for source code repositories and now the IDE has to grow to the complexity of a web browser!
Now, I do appreciate Chip's integrated vision from silicon to programming language to IDE. I'm sure that vision can be maintained even without desperately clinging onto old fashioned ways.
As an example, the Parallax font may well be in the Propeller but it is not in the P2. In the P2 future why would we still be desperately clinging to that font?
I think the vision can be maintained just as well with UTF-8 as with UTF-16. That's just an implementation detail that does not affect the look, feel, or performance of the IDE. I assume UTF-16 was chosen originally since all characters are the same "width" and, therefore, easier to scan and parse.
Somebody mentioned adding the ability to include schematics as images in the source code. Nice idea but now the IDE has to understand a ton of image formats, PNG, GIF, JPG, etc or even the source code of those images, svg, scm, whatever. Binary images are bad news for source code repositories and now the IDE has to grow to the complexity of a web browser!
I've already mooted that requirement with my AutoDoc program. The IDE does not have to be a web browser for the source code to have useful, minimally-invasive markup that the AutoDoc program converts to "pretty" HTML for display in the user's default browser. I have not yet implemented image file display beyond the Parallax font drawings, but including images in embedded base64 comments is definitely not a stretch. That way the code and its documentation are completely self-contained in a single file without placing any additional burdens on the IDE.
3) Putting schematics into source code as ASCII art is a bad idea. Changing from ASCII to UTF16 is even worse. Having to use a particular font to make that work is even worse. This has to go for the sake of every ones sanity.
I see you did qualify the initial sweeping 'bad idea' claim - I agree font-based Schematics are not a good way forward, but here we use a lot of Courier/fixed font ASCII Art schematics, and they are very useful to have.
The attraction is they simply sit in the source, and are instantly viewable in any editor.
Sometimes we enter these manually, but mostly I use AAcircuit CAD tool, and paste via the clipboard.
Likewise, Timing diagrams in ASCII are very common in our source. (Also Courier/fixed font based).
Yes, I agree. It does not matter what the compiler/editors internal representation of strings is. JavaScript for example uses UCS-2 or UTF-16 internally.
As long as output is UTF-8 we are good to go. Of course it should be able to read the other unicode formats.
Be aware though that UTF-16 does not have fixed width character sizes. UTF-16 is a variable length encoding that can represent 1,112,064 possible characters in Unicode with one or two 16 bit code units.
UCS-2 is the old 16 bit format that is fixed length and can only represent inicode code points 0 to 0xffff.
This whole unicode mess gets exponentially more complex the more you look at it.
I fundamentally disagree with the idea of binary blobs for drawings or whatever in source code files. "Source code" should be what is says. It should be human readable it should be diff'able for tools like source code repositories, git, etc.
One could imagine that schematics and other drawings do actually have a source representation, could be svg, xml. Or what about EDIF http://en.wikipedia.org/wiki/EDIF. In that way the schematic is in user editable form as source code should be.
Hmmm...looks like original ASCII art is what I would prefer, given the criteria of display anywhere and user editability. No special fonts required.
Ultimately if what we are creating has any worth and can be reused by others it should be in a source management systems repo. Any supporting documentation would be in there as well. The whole thing would be a self contained. Think repositories not individual source files. git will do nicely.
Omnia Creator can open propeller utf-16 files and display custom parallax symbols more of less correctly as long as the parallax font is selected. There is no support for entering the glyphs but you can at least read files that have them.
A quick question... I think I read above that the SimpleIDE can be used for C and Spin. Is that correct? Not a big thing... just curious, cuz I don't see any way to program Spin.
Yes, SimpleIDE can do Spin, it is a little inconvenient, but it can be done. First, you have to get out of Simple mode, and get into Project mode, then you can specify the compiler that you want to use. I have a feeling that Parallax might be phasing out the Spin part of SimpleIDE.
Now, the problem with that, for me of course, is, now you have to deal with two IDE programs. Now, if Bean comes up with an IDE for PropBasic, then we only have three IDE programs to deal with, and so on.
To bad somebody can't come up with a nice solution for adding in a sensible PropGCC to the PropellerIDE, just my two cents.
Yes, SimpleIDE can do Spin, it is a little inconvenient, but it can be done. First, you have to get out of Simple mode, and get into Project mode, then you can specify the compiler that you want to use. I have a feeling that Parallax might be phasing out the Spin part of SimpleIDE.
Now, the problem with that, for me of course, is, now you have to deal with two IDE programs. Now, if Bean comes up with an IDE for PropBasic, then we only have three IDE programs to deal with, and so on.
To bad somebody can't come up with a nice solution for adding in a sensible PropGCC to the PropellerIDE, just my two cents.
I was trying to copy IR codes out of the Terminal window...
Ah, you mean PropellerIDE's Terminal window, right? You should write this up as an issue (actually 2 issues, the missing menu items & lack of Copy/Paste in the Terminal window) at:
OK, I take all that back. Seems the build instructions at https://github.com/parallaxinc/PropellerIDE are totally hopeless. Starting from the idea of installing Qt5 (Not in Debian), then the git clone link is wrong. After that it goes down hill....
The build on a Raspi fails with a complaint about a missing <QStandardPaths>
<QStandardPaths> is a Qt5 thing. Not available in Debian Wheezy or Raspian.
OK, I take all that back. Seems the build instructions at https://github.com/parallaxinc/PropellerIDE are totally hopeless. Starting from the idea of installing Qt5 (Not in Debian), then the git clone link is wrong. After that it goes down hill....
The build on a Raspi fails with a complaint about a missing <QStandardPaths>
<QStandardPaths> is a Qt5 thing. Not available in Debian Wheezy or Raspian.
Try the old version on googlecode with normal qt.
I built it before, no problem. Here's a package.
Thank you for posting! Your post will not be visible until a moderator has approved it for posting. You will now be taken back to the forum. If you opted to post a poll, you will now be allowed to do so.
That drive by google link refers to a file called "PropellerIDE-0-19.armv6l.raspberrypi-linux.tar.bz2".
Which sounds like it might be useful.
Is there any way I can "wget" that onto my Pi?
I don't even see a way to down load it to this Windows machine I'm typing on.
Edit: OK I finally hit the right icon to get a download to somewhere in this Windows laptop.
But, that is not what I'm about, I don't want ready made binaries. I want build instructions. It's a Qt app. If we can't build Qt apps on all supported platforms there is something very wrong.
But, that is not what I'm about, I don't want ready made binaries. I want build instructions. It's a Qt app. If we can't build Qt apps on all supported platforms there is something very wrong.
LOL. Take it or leave it.
If the old repo can be built and run (the binary is proof), surely the new one can be built too.
@Heater, @Bill I have successfully compiled the latest Propeller IDE ( from Brett's own repository ) on the Raspberry Pi, against Qt5 libs from a backports repository. There are a few steps, but it absolutely definitely works!
These instructions are for Raspbian.
First you'll need Qt5, so edit /etc/apt/sources.list and add:
deb http://twolife.be/raspbian/ wheezy main backports
deb-src http://twolife.be/raspbian/ wheezy main backports
This will take some time, and install a plethora of packages.
Next, you need to tweak the makefile, if it's not already up to scratch. Open it up and make sure that underneath all the CPU := sections you force the CPU to armhf, like so:
CPU := armhf
Finally:
make checkout
make deb
And eat lunch!
When you return from lunch, there should be a deb file in a staging folder. Just:
sudo dpkg -i propelleride-0.0.0-phony-armhf.deb
If it's got "arm6l" in the name instead, it likely wont install and you'll need to double-check your edits to the makefile.
When you first fire up Propeller IDE, do it from LXTerminal. Start up the Terminal and run: propelleride
This will let you see any output and figure out what dependencies might still be missing. If you find any, let me know.
A common issue is silent dependency failures behind xcb. You can figure out what's missing by running: ldd /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqxcb.so
Sadly I have no way to play with it today, my big flat Samsung monitor has exploded. Well, started to get very hot in one corner then expired. It was the only screen I could connect to a Pi around here.
Do you happen to know: Does the Qt5 installation form twolife supports OpenGl/GLES? Does it support running apps directly in the frame buffer, no X Window system?
Now, since explicitly detecting the Raspberry Pi's armhf architecture was problematic. I haven't had time to try it myself yet, but it could well work. Note, it might be in his fork only at the moment, but I highly recommend pulling from there anyway- he's gutting PropellerIDE and doing some really awesome things with it!
@Heater I'm not sure about running directly in the frame buffer, but the PropellerIDE wont start without libgles2-mesa, which makes me assume that it's at least somewhat accelerated. I'm not huge on Qt though, so I've no idea!
@Bill - thank you. I'm really pushing for good solid Raspberry Pi support for a product we're ( Pimoroni ) launching shortly, Propeller HAT. It's a Propeller, on a HAT in simple terms. With a breadboard. I'm pitching it as the Pi's answer to the Beaglebone PRU... except better, obviously Hopefully your customers will see the benefits of this push too! The work Brett is doing on PropellerIDE is ace, and he's gradually improving performance alongside a dozen other things, it already blows the Arduino IDE out of the water on the Pi. ( and everywhere else really )
Whoo hoo! Running fine on Linux Mint 17.1. Thanks for your efforts!
one discoverd bug (sorry, im late to this thread, it may have alredy been reported):
If i try to open open a file from the object list of a project by clicking on the file name, the file does not open. instead a new blank tab is opened. Sometimes a new tab will open, but the entire body of code will be one long line of text... see screen shot.
Whoo hoo! Running fine on Linux Mint 17.1. Thanks for your efforts!
one discoverd bug (sorry, im late to this thread, it may have alredy been reported):
If i try to open open a file from the object list of a project by clicking on the file name, the file does not open. instead a new blank tab is opened. Sometimes a new tab will open, but the entire body of code will be one long line of text... see screen shot.
Hi Rogersysd, this is actually a file encoding problem, specifically with opening Windows text files on Linux, as the line endings are different. Would you call
file
on the text file you're opening and paste the output here?
It would probably be a good idea to auto-convert line endings when files are first opened, but it would take some work to get a clean implementation.
To resolve your current problem, my first line of attack would be to install
dos2unix
(it may already be installed) and run it on your file. Some version control systems (like Git) also automatically check out your files with the correct line endings, so if you find yourself moving between platforms a lot, that would help a lot.
Comments
Here is the other thing:
1) Whilst having feature parity with the old Prop Tool is desirable I see no reason to carry miss-features forward into the modern world. They are a shackle that inconveniences everyone and wastes development effort that could be better used elsewhere.
2) Using UTF-16 in the modern world is just dumb. Everyone realized the problems with that a long time ago and UTF-8 is the result. Clearly a Prop Tool replacement should use UTF-8
(Aside: Being an older guy I think moving away from ASCII is a big mistake
3) Putting schematics into source code as ASCII art is a bad idea. Changing from ASCII to UTF16 is even worse. Having to use a particular font to make that work is even worse. This has to go for the sake of every ones sanity.
4) Having my code editing experience be dependent on a custom font is just silly.
5) Creating an editor/IDE that is required to support all that cruft is a pain. For example a WEB IDE like msrobots Editor17
Somebody mentioned adding the ability to include schematics as images in the source code. Nice idea but now the IDE has to understand a ton of image formats, PNG, GIF, JPG, etc or even the source code of those images, svg, scm, whatever. Binary images are bad news for source code repositories and now the IDE has to grow to the complexity of a web browser!
Now, I do appreciate Chip's integrated vision from silicon to programming language to IDE. I'm sure that vision can be maintained even without desperately clinging onto old fashioned ways.
As an example, the Parallax font may well be in the Propeller but it is not in the P2. In the P2 future why would we still be desperately clinging to that font?
I've already mooted that requirement with my AutoDoc program. The IDE does not have to be a web browser for the source code to have useful, minimally-invasive markup that the AutoDoc program converts to "pretty" HTML for display in the user's default browser. I have not yet implemented image file display beyond the Parallax font drawings, but including images in embedded base64 comments is definitely not a stretch. That way the code and its documentation are completely self-contained in a single file without placing any additional burdens on the IDE.
-Phil
I see you did qualify the initial sweeping 'bad idea' claim - I agree font-based Schematics are not a good way forward, but here we use a lot of Courier/fixed font ASCII Art schematics, and they are very useful to have.
The attraction is they simply sit in the source, and are instantly viewable in any editor.
Sometimes we enter these manually, but mostly I use AAcircuit CAD tool, and paste via the clipboard.
Likewise, Timing diagrams in ASCII are very common in our source. (Also Courier/fixed font based).
Yes, I agree. It does not matter what the compiler/editors internal representation of strings is. JavaScript for example uses UCS-2 or UTF-16 internally.
As long as output is UTF-8 we are good to go. Of course it should be able to read the other unicode formats.
Be aware though that UTF-16 does not have fixed width character sizes. UTF-16 is a variable length encoding that can represent 1,112,064 possible characters in Unicode with one or two 16 bit code units.
UCS-2 is the old 16 bit format that is fixed length and can only represent inicode code points 0 to 0xffff.
This whole unicode mess gets exponentially more complex the more you look at it.
I fundamentally disagree with the idea of binary blobs for drawings or whatever in source code files. "Source code" should be what is says. It should be human readable it should be diff'able for tools like source code repositories, git, etc.
One could imagine that schematics and other drawings do actually have a source representation, could be svg, xml. Or what about EDIF http://en.wikipedia.org/wiki/EDIF. In that way the schematic is in user editable form as source code should be.
Hmmm...looks like original ASCII art is what I would prefer, given the criteria of display anywhere and user editability. No special fonts required.
Ultimately if what we are creating has any worth and can be reused by others it should be in a source management systems repo. Any supporting documentation would be in there as well. The whole thing would be a self contained. Think repositories not individual source files. git will do nicely.
Thanks for any enlightenment!
@
Now, the problem with that, for me of course, is, now you have to deal with two IDE programs. Now, if Bean comes up with an IDE for PropBasic, then we only have three IDE programs to deal with, and so on.
To bad somebody can't come up with a nice solution for adding in a sensible PropGCC to the PropellerIDE, just my two cents.
Ray
Ah... found it. Thank you, Sir!
@
I'm trying to copy some text from the terminal window... Is there any way to do that?
Yeah, no menu items for Copy/Paste. Just use Command-C for Copy and Command-V for paste. Those menu items should be added to the project...
dgately
Ah, you mean PropellerIDE's Terminal window, right? You should write this up as an issue (actually 2 issues, the missing menu items & lack of Copy/Paste in the Terminal window) at:
https://lamestation.atlassian.net/browse/IDE-61?jql=project%20%3D%20IDE
dgately
-Phil
I downloaded the zip, and while there was a make file, it was not for Linux
Shamefully I have not tried compiling PropellerIDE on an ARM. Not even a Raspi.
Generally the deal is you need to have Qt available on the platform and the run "qmake" which will generate the required Makefile.
Then you can run "make"
OK, I take all that back. Seems the build instructions at https://github.com/parallaxinc/PropellerIDE are totally hopeless. Starting from the idea of installing Qt5 (Not in Debian), then the git clone link is wrong. After that it goes down hill....
The build on a Raspi fails with a complaint about a missing <QStandardPaths>
<QStandardPaths> is a Qt5 thing. Not available in Debian Wheezy or Raspian.
Try the old version on googlecode with normal qt.
I built it before, no problem. Here's a package.
Merry New Year.
Thank you for posting! Your post will not be visible until a moderator has approved it for posting. You will now be taken back to the forum. If you opted to post a poll, you will now be allowed to do so.
Try this RPi v0.19 propelleride binary.
https://drive.google.com/file/d/0BzcfH7bdVTbtaFphaGxQVUwxMjQ/view?usp=sharing
That drive by google link refers to a file called "PropellerIDE-0-19.armv6l.raspberrypi-linux.tar.bz2".
Which sounds like it might be useful.
Is there any way I can "wget" that onto my Pi?
I don't even see a way to down load it to this Windows machine I'm typing on.
Edit: OK I finally hit the right icon to get a download to somewhere in this Windows laptop.
But, that is not what I'm about, I don't want ready made binaries. I want build instructions. It's a Qt app. If we can't build Qt apps on all supported platforms there is something very wrong.
LOL. Take it or leave it.
If the old repo can be built and run (the binary is proof), surely the new one can be built too.
You know me. Now I'm going to have to hammer on the damn thing until it does build on my Pi.
Like SimpleIDE before it
These instructions are for Raspbian.
First you'll need Qt5, so edit /etc/apt/sources.list and add:
Then get Qt5 and esoteric requirements installed:
This will take some time, and install a plethora of packages.
Next, you need to tweak the makefile, if it's not already up to scratch. Open it up and make sure that underneath all the CPU := sections you force the CPU to armhf, like so:
Finally:
And eat lunch!
When you return from lunch, there should be a deb file in a staging folder. Just:
If it's got "arm6l" in the name instead, it likely wont install and you'll need to double-check your edits to the makefile.
When you first fire up Propeller IDE, do it from LXTerminal. Start up the Terminal and run: propelleride
This will let you see any output and figure out what dependencies might still be missing. If you find any, let me know.
A common issue is silent dependency failures behind xcb. You can figure out what's missing by running: ldd /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqxcb.so
Good luck!
Sadly I have no way to play with it today, my big flat Samsung monitor has exploded. Well, started to get very hot in one corner then expired. It was the only screen I could connect to a Pi around here.
Do you happen to know: Does the Qt5 installation form twolife supports OpenGl/GLES? Does it support running apps directly in the frame buffer, no X Window system?
I will try it this weekend, and if it works, I'll see if a variation will work on SimpleIDE.
Now, since explicitly detecting the Raspberry Pi's armhf architecture was problematic. I haven't had time to try it myself yet, but it could well work. Note, it might be in his fork only at the moment, but I highly recommend pulling from there anyway- he's gutting PropellerIDE and doing some really awesome things with it!
@Heater I'm not sure about running directly in the frame buffer, but the PropellerIDE wont start without libgles2-mesa, which makes me assume that it's at least somewhat accelerated. I'm not huge on Qt though, so I've no idea!
@Bill - thank you. I'm really pushing for good solid Raspberry Pi support for a product we're ( Pimoroni ) launching shortly, Propeller HAT. It's a Propeller, on a HAT in simple terms. With a breadboard. I'm pitching it as the Pi's answer to the Beaglebone PRU... except better, obviously
one discoverd bug (sorry, im late to this thread, it may have alredy been reported):
If i try to open open a file from the object list of a project by clicking on the file name, the file does not open. instead a new blank tab is opened. Sometimes a new tab will open, but the entire body of code will be one long line of text... see screen shot.
Hi Rogersysd, this is actually a file encoding problem, specifically with opening Windows text files on Linux, as the line endings are different. Would you call on the text file you're opening and paste the output here?
It would probably be a good idea to auto-convert line endings when files are first opened, but it would take some work to get a clean implementation.
To resolve your current problem, my first line of attack would be to install (it may already be installed) and run it on your file. Some version control systems (like Git) also automatically check out your files with the correct line endings, so if you find yourself moving between platforms a lot, that would help a lot.