Well I went ahead and re-installed Debian Gnome, I guess I will just have to get used to it. I installed Qt5, which went very smooth, got the latest clone of Propeller IDE, and made sure that g++ is installed on the system. When I hit the green button, in Qt Creator, it goes through a build and comes up with an error: "GL/gl.h - No such file or directory". Boy am I having a lousy time with this Linux stuff. Now I am not sure where I have to find "GL/gl.h". Besides Heater, is anybody else doing business with Debian Gnome for building Propeller IDE?
Ray
Ray,
Works for me... I'm on a most-recent Debian 7 64-Bit install into a VMWare VM, running on my MacBook Pro.
Success, after adding that mesa-common... stuff, finally got a glimpse of Propeller IDE running on Debian. Now for the real challange, getting and compiling openspin and propeller-load. I don't suppose anybody has done that already?
As for the terminal discussion, my vote, if counts for anything, NO to the split window. I have used CuteCom, and I thought it was a horrible experience. When I have used PST, I did not like that one either. Just my two cents.
Ray
Figures, you solved just as I was typing
For openspin & propeller-load, you could download SimpleIDE (source or I think there is a linux download) and it will "do the right thing" in getting those tools in-place during its build or installation. openspin will build with just a command-line "make all". For propeller-load, you can build progcc...
I generally follow SimpleIDE's installation and put the executables into "/opt/parallax/bin/" when I need to.
More on Debian.
I found openspin and propeller-load from the SimpleIDE download to Debian. When I did my test blinker.spin program, the 'build' part works fine, but when I tried a 'run', it comes back with a PropellerIDE error- "Could not start loader.". So I am not sure if there is a problem with the propeller-load program, execute mode is checked, or is it something in Propeller IDE.
I am kind of liking this, a really quick and dirty write it and run it setup, no fancy dodads, just a quick way of getting a Spin program running. Now is there any magic setup for a quick and dirty PropGCC?:-)
I think later I'll add the PLoadLib code to the repo. Using it, a very simple loader can be created, and you don't need the propeller-gcc repository to build it. Will add instructions.
David Betz mentioned creating a terminal GUI with a loader built-in. I think that is a perfect idea longer term because it will provide even people who don't need to compile a spin program a useful GUI, and it should be possible to run more than one terminal at a time without the Propeller IDE.
I think later I'll add the PLoadLib code to the repo. Using it, a very simple loader can be created, and you don't need the propeller-gcc repository to build it. Will add instructions.
David Betz mentioned creating a terminal GUI with a loader built-in. I think that is a perfect idea longer term because it will provide even people who don't need to compile a spin program a useful GUI, and it should be possible to run more than one terminal at a time without the Propeller IDE.
Is there a problem with needing propgcc to build the loader? Is it a requirement of this project that it be able to be built without propgcc? Why?
It should not be necessary for anyone to need propeller-gcc just to get a loader for this project.
You've got to be kidding. You need to be able to build this without PropGCC? Or are you saying you shouldn't need to have PropGCC installed to run the resulting PropellerIDE executable?
I assume it's for bits of stuff like XMM or whatever. Stuff that we don't need at all. It would be nice if the loading of ram and/or eeprom was integrated into the app like with proptool, in my opinion.
I assume it's for bits of stuff like XMM or whatever. Stuff that we don't need at all. It would be nice if the loading of ram and/or eeprom was integrated into the app like with proptool, in my opinion.
Fine. I'm off the project. I hope you all have a good time.
I assume it's for bits of stuff like XMM or whatever. Stuff that we don't need at all. It would be nice if the loading of ram and/or eeprom was integrated into the app like with proptool, in my opinion.
Roy,
Having the loader run as it's own program easily solves certain timing issues required by the Propeller. You're welcome to add such a feature after first cut.
Hi, I've imported the Editor and Syntax highlighter classes from SimpleIDE.
Spin text should be pretty now (background shading is not a first cut requirement).
Windows box.
When I run the Qt Creator on the latest clone:
Starting C:\programming\easyside\propide\build-EzIDE-Desktop_Qt_5_2_1_MinGW_32bit-Debug\debug\PropellerIDE.exe...
QObject::connect: No such signal MainWindow::highlightCurrentLine(QColor) in ..\ide\editor.cpp:24
"Event 19"
C:\programming\easyside\propide\build-EzIDE-Desktop_Qt_5_2_1_MinGW_32bit-Debug\debug\PropellerIDE.exe exited with code 0
Other than that, it looks good. Now I will have to try out the Debian box.
Starting /home/ray/programming/propide2/build-EzIDE-Desktop_Qt_5_2_1_GCC_64bit-Debug/PropellerIDE...
"Event 19"
/home/ray/programming/propide2/build-EzIDE-Desktop_Qt_5_2_1_GCC_64bit-Debug/PropellerIDE exited with code 0
Now when I run Propeller IDE, the difference between the windows box and the Debian box, on the Debian box, Propeller IDE does not show the line numbers. I also still get the "Can't start loader" error, other than that, it looks good.
Why would you react like that? I wasn't attacking anything, just stating what I thought... And my comments only apply to this IDE for spin/pasm.
My plan had been to write a separate loader/terminal GUI that would be invoked by either PropellerIDE or SimpleIDE. If it is required to build without propgcc installed then it will not be possible to use it with PropellerIDE. It is actually the SD card support that requires propgcc not only XMM support by the way. Anyway, I guess I need to do my loader/terminal project separate from this project.
My plan had been to write a separate loader/terminal GUI that would be invoked by either PropellerIDE or SimpleIDE. If it is required to build without propgcc installed then it will not be possible to use it with PropellerIDE. It is actually the SD card support that requires propgcc not only XMM support by the way. Anyway, I guess I need to do my loader/terminal project separate from this project.
I seriously don't understand the problem here.
I've already stated that I welcome the plan to have a separate loader and terminal GUI. IMHO, it is a great long term solution.
However I don't see why it is necessary to have propeller-gcc installed to do this. At some point I'll make a (compile-time selected) version of this GUI that uses propeller-gcc, but that shouldn't mean that propeller-gcc should be installed by a spin-only version user.
A separate thread for the loader/terminal GUI is fine of course because it would be best to hammer out requirements and other details separately.
I've already stated that I welcome the plan to have a separate loader and terminal GUI. IMHO, it is a great long term solution.
However I don't see why it is necessary to have propeller-gcc installed to do this. At some point I'll make a (compile-time selected) version of this GUI that uses propeller-gcc, but that shouldn't mean that propeller-gcc should be installed by a spin-only version user.
A separate thread for the loader/terminal GUI is fine of course because it would be best to hammer out requirements and other details separately.
The loader I was planning on writing is basically a GUI version of propeller-load and that requires propgcc to build. The reason is that there is some Propeller C code that is needed by some of the propeller-load functions and that has to be compiled with propgcc. I suppose you could add a bunch of ifdefs to leave that out for PropellerIDE but I don't see what the problem is with requiring propgcc to be installed. It's not like it has to be installed by users of PropellerIDE. It just needs to be installed to build it.
It's not like it has to be installed by users of PropellerIDE. It just needs to be installed to build it.
That's an important distinction.
I don't mind using propeller-gcc, but there are others here who do.
If anyone objects to needing propeller-gcc to build the loader/terminal GUI, then they should speak up, but if an abusive fight erupts over it, then that is unacceptable.
I still think it's a good idea to have a separate thread anyway to keep things from getting confused. Besides, there are other users of such a GUI who don't need the editor and compiler parts of the PropellerIDE, and I'm sure they will love your GUI.
Another thing I'd like to consider for this loader/terminal GUI is having its main program separate from a loader widget and terminal widget. The idea would be that at some point it might be possible to link these widgets directly with an IDE to avoid having to invoke a separate program.
BTW: The interaction between P-Tool and the Parallax Terminal has always been somewhat frustrating to me personally. In fact, I went ahead and got good at video related things early on so that I could just use a keyboard and display for debug output because I disliked the serial experience overall.
I've revisited it while mentoring somebody, and I like serial a lot. But I don't like having to enable, disable, "oops, lost focus" kind of thing. For my own purposes, I either use a video display, or I'll use two Prop Plugs and just have one dedicated to an open Putty window, or my Apple ][ frankly (just because it's fun, and it does make a perfectly fine terminal), and the other dedicated to programming. That way, the terminal just always works, and it's focus does not matter, or it doesn't have a focus, etc...
Doing that does not always make sense, and the idea of having a loader / terminal with a better UX model is appealing. I'll bet it sees fairly solid and rapid adoption, if it gets past the basic tedium and "just works."
Re: Build vs Install
Personally, how it's built should not be an issue. Take the most robust path of least resistance. It's hard enough to get things made. Making it harder does not make sense.
For an install, surely the relevant bits can be packaged up in a way users will feel good about. Disks are cheap and none of this stuff is so big as to be a real issue. Most important to present what the user is looking for, and anything else needing to come along for the ride just needs to be "in the back seat" out of the way, IMHO.
BTW: The interaction between P-Tool and the Parallax Terminal has always been somewhat frustrating to me personally. In fact, I went ahead and got good at video related things early on so that I could just use a keyboard and display for debug output because I disliked the serial experience overall.
I've revisited it while mentoring somebody, and I like serial a lot. But I don't like having to enable, disable, "oops, lost focus" kind of thing. For my own purposes, I either use a video display, or I'll use two Prop Plugs and just have one dedicated to an open Putty window, or my Apple ][ frankly (just because it's fun, and it does make a perfectly fine terminal), and the other dedicated to programming. That way, the terminal just always works, and it's focus does not matter, or it doesn't have a focus, etc...
Doing that does not always make sense, and the idea of having a loader / terminal with a better UX model is appealing. I'll bet it sees fairly solid and rapid adoption, if it gets past the basic tedium and "just works."
Re: Build vs Install
Personally, how it's built should not be an issue. Take the most robust path of least resistance. It's hard enough to get things made. Making it harder does not make sense.
For an install, surely the relevant bits can be packaged up in a way users will feel good about. Disks are cheap and none of this stuff is so big as to be a real issue. Most important to present what the user is looking for, and anything else needing to come along for the ride just needs to be "in the back seat" out of the way, IMHO.
This is the reason that I want to put the loader in the same program as the terminal emulator. Then that window can always have "focus" and you won't lose anything between the load finishing and the terminal window becoming active. This would be true whether the loader/terminal is a separate program or if it is linked with the IDE.
If anyone objects to needing propeller-gcc to build the loader/terminal then they should object to needing gcc or minGW to build PropellerIDE...and that's just getting silly.
That's like not wanting to use the S2 GUI just because it is written in Perl or not buying an android phone because android is written in Java...at somepoint it really has to come down to the end result tool and not what you used to create it.
I see David's loader/terminal as a great asset for many users and because of that it should be a stand alone project with a tightly coordinated interface to the *IDE projects.
I'm looking forward to adapting it as a tool for F____ development. How useful to be able to load various interpreter binaries and then have a good terminal to use...maybe even one that knows when the load is complete and the terminal can use the port.
+bunches to Potatohead's comments about PropellerTool and Propeller Terminal, talk about a pothole in the middle of you seamless coding experience!!
Is there a problem with needing propgcc to build the loader? Is it a requirement of this project that it be able to be built without propgcc? Why?
I had only responded to Ray's question about how to get the loader on to his Linux system, at this time. No doubt Propeller iDE will eventually take care of this need, but someone that wants to test the app now, needs to get a loader from somewhere...
I hope I didn't light a flame... I was just trying to help Ray get the IDE up for his testing.
Comments
Ray,
Works for me... I'm on a most-recent Debian 7 64-Bit install into a VMWare VM, running on my MacBook Pro.
Qt download: http://qt-project.org/downloads
Be sure to get one of these open-source Qt 5.2.1 downloads...
This installs Qt 5.2.1 & Qt Creator 3.0.1... Is that what you installed?
dgately
Figures, you solved just as I was typing
For openspin & propeller-load, you could download SimpleIDE (source or I think there is a linux download) and it will "do the right thing" in getting those tools in-place during its build or installation. openspin will build with just a command-line "make all". For propeller-load, you can build progcc...
I generally follow SimpleIDE's installation and put the executables into "/opt/parallax/bin/" when I need to.
dgately
I found openspin and propeller-load from the SimpleIDE download to Debian. When I did my test blinker.spin program, the 'build' part works fine, but when I tried a 'run', it comes back with a PropellerIDE error- "Could not start loader.". So I am not sure if there is a problem with the propeller-load program, execute mode is checked, or is it something in Propeller IDE.
I am kind of liking this, a really quick and dirty write it and run it setup, no fancy dodads, just a quick way of getting a Spin program running. Now is there any magic setup for a quick and dirty PropGCC?:-)
Ray
I think later I'll add the PLoadLib code to the repo. Using it, a very simple loader can be created, and you don't need the propeller-gcc repository to build it. Will add instructions.
David Betz mentioned creating a terminal GUI with a loader built-in. I think that is a perfect idea longer term because it will provide even people who don't need to compile a spin program a useful GUI, and it should be possible to run more than one terminal at a time without the Propeller IDE.
for now, since i'm not a skilled C programmer, I suppose I can help with testing
so, here's my first feedback:
Debian Wheezy -not fully updated- with KDE
Ok
Go to http://qt-project.org/downloads and download
Qt 5.2.1 for Linux 32-bit (371 MB)
after many hours...
double click from dolphin, select install path, next, next, next
run now. ..... QT 5 and QTCreator installed!!!
Load EzIDE.pro
on project properties, select only Qt 5 for compilation.
menu build, build all
after some minutes, on "Compile Output" There is a message:
PropellerIDE compiled!!
Navigate to easyside folder. there is a new folder
build-EzIDE-Desktop_Qt_5_2_1_GCC_32bit-Debug
double click to propeller IDE.
Voil
I'm not even sure why a prop loader tool needs propeller-gcc at all?
Why would you react like that? I wasn't attacking anything, just stating what I thought...
Roy,
Having the loader run as it's own program easily solves certain timing issues required by the Propeller. You're welcome to add such a feature after first cut.
Spin text should be pretty now (background shading is not a first cut requirement).
That works nicely.
David,
What's up?
When I run the Qt Creator on the latest clone: Other than that, it looks good. Now I will have to try out the Debian box.
Ray
On this Qt Creator build I get: Now when I run Propeller IDE, the difference between the windows box and the Debian box, on the Debian box, Propeller IDE does not show the line numbers. I also still get the "Can't start loader" error, other than that, it looks good.
Ray
I seriously don't understand the problem here.
I've already stated that I welcome the plan to have a separate loader and terminal GUI. IMHO, it is a great long term solution.
However I don't see why it is necessary to have propeller-gcc installed to do this. At some point I'll make a (compile-time selected) version of this GUI that uses propeller-gcc, but that shouldn't mean that propeller-gcc should be installed by a spin-only version user.
A separate thread for the loader/terminal GUI is fine of course because it would be best to hammer out requirements and other details separately.
That's an important distinction.
I don't mind using propeller-gcc, but there are others here who do.
If anyone objects to needing propeller-gcc to build the loader/terminal GUI, then they should speak up, but if an abusive fight erupts over it, then that is unacceptable.
I still think it's a good idea to have a separate thread anyway to keep things from getting confused. Besides, there are other users of such a GUI who don't need the editor and compiler parts of the PropellerIDE, and I'm sure they will love your GUI.
I've revisited it while mentoring somebody, and I like serial a lot. But I don't like having to enable, disable, "oops, lost focus" kind of thing. For my own purposes, I either use a video display, or I'll use two Prop Plugs and just have one dedicated to an open Putty window, or my Apple ][ frankly (just because it's fun, and it does make a perfectly fine terminal), and the other dedicated to programming. That way, the terminal just always works, and it's focus does not matter, or it doesn't have a focus, etc...
Doing that does not always make sense, and the idea of having a loader / terminal with a better UX model is appealing. I'll bet it sees fairly solid and rapid adoption, if it gets past the basic tedium and "just works."
Re: Build vs Install
Personally, how it's built should not be an issue. Take the most robust path of least resistance. It's hard enough to get things made. Making it harder does not make sense.
For an install, surely the relevant bits can be packaged up in a way users will feel good about. Disks are cheap and none of this stuff is so big as to be a real issue. Most important to present what the user is looking for, and anything else needing to come along for the ride just needs to be "in the back seat" out of the way, IMHO.
That's like not wanting to use the S2 GUI just because it is written in Perl or not buying an android phone because android is written in Java...at somepoint it really has to come down to the end result tool and not what you used to create it.
I see David's loader/terminal as a great asset for many users and because of that it should be a stand alone project with a tightly coordinated interface to the *IDE projects.
I'm looking forward to adapting it as a tool for F____ development. How useful to be able to load various interpreter binaries and then have a good terminal to use...maybe even one that knows when the load is complete and the terminal can use the port.
+bunches to Potatohead's comments about PropellerTool and Propeller Terminal, talk about a pothole in the middle of you seamless coding experience!!
I had only responded to Ray's question about how to get the loader on to his Linux system, at this time. No doubt Propeller iDE will eventually take care of this need, but someone that wants to test the app now, needs to get a loader from somewhere...
I hope I didn't light a flame... I was just trying to help Ray get the IDE up for his testing.
dgately