I only started my EzIDE from Creator by hitting the green Run button, when the property window came up I just hit cancel and the property window closed. In my EzIDE folder, QT created another folder(build-EzIDE-Desktop ...) which has a debug folder which has an EzIDE application, but when I run it, it complains with: The program can't start because Qt5Cored.dll is missing ... I must have missed something in my tool chain.
Ray
No, it's all there. You just have to have the libraries in your path. Find Qt5Cored.dll, and add it's folder to your PATH variable.
I only started my EzIDE from Creator by hitting the green Run button, when the property window came up I just hit cancel and the property window closed. In my EzIDE folder, QT created another folder(build-EzIDE-Desktop ...) which has a debug folder which has an EzIDE application, but when I run it, it complains with: The program can't start because Qt5Cored.dll is missing ... I must have missed something in my tool chain.
Ray
Ray,
Try building a "Release" version of the app. It should provide you with a non-Debug version that will run outside of QT Creator... (I think!)
The full Error message:
The program can't start because Qt5Cored.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I did a search of my computer for Qt5Cored.dll, and nothing could be found. I guess this will be my first set back, now I have to decide if I should uninstall MinGW and Qt5 or just Qt5?
The full Error message:
The program can't start because Qt5Cored.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I did a search of my computer for Qt5Cored.dll, and nothing could be found. I guess this will be my first set back, now I have to decide if I should uninstall MinGW and Qt5 or just Qt5?
Ray
You have everything you need except knowing where to look for the libraries and how to add the the paths.
Where is Qt installed?
Mine is here C:\Qt
The .dlls are here: C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin
Assuming that's where your folder lives, add the path on the command window as:
set PATH=C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin\;%PATH%
No joy. After uninstalling and re-installing Qt5, plus setting the path as per your suggestion, I am still getting that pesky little error. I have Qt5 in C:\, so the setting of the path example should of did the trick.
I think tomorrow I will try this again on my xubuntu box, and see how far I can get. If I am successful how do I get an openspin, and other support files to work on the xubuntu box Qt5 setup?
I was going to recommend just using QtCreator to run this thing
Started a new command window. If I don't add the path, the program fails to launch. If I do the following steps, no problem. This is the best I can do for you.
I downloaded QTcreator to UBUNTU, then get xBasic away, then run in Debug, and in Release mode. Downloaded a small spinfile of Dave Hein's fast forth, changed a little. But in easyIDE it only give me the prompt, when I reset the propeller. In SimpleIde it works ok.
I downloaded QTcreator to UBUNTU, then get xBasic away, then run in Debug, and in Release mode. Downloaded a small spinfile of Dave Hein's fast forth, changed a little. But in easyIDE it only give me the prompt, when I reset the propeller. In SimpleIde it works ok.
Are you by any chance using a PPDB or Quickstart? If not, what is your Propeller board?
There were some improvements in SimpleIDE over the baseline project regarding downloads and serial terminal. I'll look into it.
I just did it through the command window as outlined by jazzed, and the program started up. So, it is a little work around, but it will suffice at this time. I will still try the xubuntu session tomorrow, maybe this is just a glitch with the windows session.
Parallax has thrown our effort behind this project. Our initial contributions are small: renaming the thread, posting an image on the first page, etc. Our next steps will bring attention to this thread from some expanded marketing communication. With the help of the community, the Propeller will begin to harvest more positive attention. Thank you for the many contributors!
Parallax has thrown our effort behind this project. Our initial contributions are small: renaming the thread, posting an image on the first page, etc. Our next steps will bring attention to this thread from some expanded marketing communication. With the help of the community, the Propeller will begin to harvest more positive attention. Thank you for the many contributors!
Ken Gracey
Won't it be confusing to have the C IDE called SImpleIDE and also the Spin IDE when the two are fairly different?
Won't it be confusing to have the C IDE called SImpleIDE and also the Spin IDE when the two are fairly different?
Perhaps not, especially if the names are descriptive like Simple IDE for C and Simple IDE for Spin. Allow them to take different forks due to design requirements, but they'll both remain simple, open, and accessible to many operating systems.
Perhaps not, especially if the names are descriptive like Simple IDE for C and Simple IDE for Spin. Allow them to take different forks due to design requirements, but they'll both remain simple, open, and accessible to many operating systems.
Ken Gracey
Does Parallax have any requirements for this project beyond what Steve has laid out already?
The problem is that this is not SimpleIDE for Spin. It's a new IDE that will not have a lot of the things that SimpleIDE has, and it will have some things that SimpleIDE does not. We don't want to imply that they are just language flavored variants of the same thing.
Also, let's not even get into the discussion that SimpleIDE is hardly Simple.
I just installed QT 5.32.1 for 32 bit Windows w/ MinGW (this one) on my Win7 Laptop. I had first installed MinGW but then realized this package had it already in it.
It will complain about missing .dll files if you try to run any standalone .exe files you create. To stop that, you need to update the PATH in your system environment variables to include: C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin
If you aren't sure how to do that, Chris Wardell tells you how to do that here.
I didn't try compiling any Spin programs since I don't have OpenSpin or the Propeller loader on this PC (I need to grab the new SimpleIDE) and it is late. I'm sure that will work based on my Mac experiences earlier today.
Can we change the name back again "Propeller IDE" was much nicer. "Spin Inside" is corny if not a little vulgar.
Also, Parallax might run into trouble with Intel. :-)
I liked Propeller IDE better too. However, aren't we supposed to be doing real work to improve this program whatever it is called rather than arguing about the name?
Anyway, getting back to talking about actual program features, I take issue with this feature mentioned in Steve's requirements:
Compile the tab-code being displayed
This is a feature that has always tripped me up in the Propeller Tool and I'd like to see it "fixed" in this new IDE. I know some people like it but I think it has more negative than positive aspects.
Now, I get why it is a trip up. Most environments write to storage, then compile. Prop Tool does not.
Here is why I like build from RAM:
If one is using source control, writing before building makes a lot of sense. There is the local copy, working copy at any time, and there is the last commit, or sync.
In this use case, it's perfectly reasonable to pull, build to verify, then change. If change makes sense, return changes to repository, and if it's a good one, like merc or git, tag, etc... leaving everything consistent. Others can pull your changes, or ignore them and pull as some date, change set, tag, whatever.
Now, if you are not using source control, things are different.
Two sub cases:
1. User understands about revisions and does the work to maintain them locally, using a file scheme
2. User does not understand this.
In case 1, open top, build to verify, perform edit and save as on all dependent files, build again to verify, then change.
To avoid the hassle, changes can be in open tabs, user commits by saving, building as needed, until a new state is reached, in which case everything is saved. If user makes ugly error, close, re open file, build again.
In case 2, user will very likely archive data, or work from an archive. The working copy is the working copy. Build from RAM may be useful to them, maybe not. Due to the unmanaged nature of things, it is most friendly to modify program, build and run and repeat, re opening the file to return to the known working state.
In both cases, it's very good for quick tweaks, or experiments that may not warrant a save. An example would be understanding something like gr.setup in the default graphics library on P1. Change it, run it, change it, run it, etc... until the desired result is obtained. Save it then.
Personally, I would love to someday see a transparent github, or google code option where the user doesn't even worry about anything other than the name and revision. I realize this is outside the scope of this project too. I'm not asking, just highlighting what I think would really help get people away from files and into managed thinking, based on my many years doing the same in the MCAD realm, where the problem is equally difficult, and "build from RAM" serves the same workflow purpose as it does here.
At the least, having this be an option would be nice. Of course it would also be nice to just have the management built in too. And have users get it. Someday
Summary: When build from RAM is in play, a user can test, learn, explore without breaking anything. Just don't save and attempt it as many times as they need / want to, no worries. If we can't build from RAM, the user must commit a change to the working copy in order to see it go, and recovering from that takes understanding they may not have. If this is about the same kinds of productivity as the Prop Tool, build from RAM is a part of that package.
I'm confused. You seriously disagree with a point about "compile the currently open tab" vs "always compile a designated top object" and then give a pros and cons argument about "compile from RAM" or "save to file then compile".
Recently I have been using the Sublime text editor. It has what I think is a nice feature in that what is on disk is always in sync with what you see in the editor. This is nice because if the thing crashes or is otherwise shut down abruptly when you start it up again there is all your work just as you left it. No lost edits and no messing with an editors back up files like with VIM. Also, if the file you have open is changed by some other editor or process at the same time the changes immediately reflect in your open view. No multiple conflicting versions live at the same time.
Of course I would not want to work without git for revision management now a days, given that it is so quick and easy.
Re: GIT. I have sometimes thought that there should be a way to use git without having to use git. If you see what I mean. It should be made transparent. Imagine, for example, that every time you hit "save" or close the editor a new git revision was made and committed and tagged. The revisions tag could just be an advancing number or perhaps the date/time. A commit comment would optional, perhaps a dialog box on save would prompt for some comment to be input. Then when the users messes up his code with his latest experiment he could just hit a "back" button which would load up the previous revision. Repeatedly hitting "back" would step you back further in time. A "forward" button would step your forwards in time.
There we have it, simple but effective revision control. Rather like the good old days of the VMS operating system which would keep multiple versions of files automatically for you.
One can use git from within an application using libgit, it is not necessary to use the command line interface or a GUI tool. So this sort of thing should be possible.
As for "compile current open" vs "compile top object" I'm not fussy.
Comments
No, it's all there. You just have to have the libraries in your path. Find Qt5Cored.dll, and add it's folder to your PATH variable.
Ray,
Try building a "Release" version of the app. It should provide you with a non-Debug version that will run outside of QT Creator... (I think!)
dgately
The program can't start because Qt5Cored.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I did a search of my computer for Qt5Cored.dll, and nothing could be found. I guess this will be my first set back, now I have to decide if I should uninstall MinGW and Qt5 or just Qt5?
Ray
You have everything you need except knowing where to look for the libraries and how to add the the paths.
Where is Qt installed?
Mine is here C:\Qt
The .dlls are here: C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin
Assuming that's where your folder lives, add the path on the command window as:
set PATH=C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin\;%PATH%
Then try it again.
I'm seeing the same issue as Ray.
Runs fine in Qt Creator but I get the missing qt5core.dll or qt5cored.dll depending on if I try to run the release or debug versions.
The files are at "C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin" on my machine and I have the path set.
C.W.
I think tomorrow I will try this again on my xubuntu box, and see how far I can get. If I am successful how do I get an openspin, and other support files to work on the xubuntu box Qt5 setup?
Ray
I was going to recommend just using QtCreator to run this thing
Started a new command window. If I don't add the path, the program fails to launch. If I do the following steps, no problem. This is the best I can do for you.
There were some improvements in SimpleIDE over the baseline project regarding downloads and serial terminal. I'll look into it.
Ray
Those steps work from a command window. The path setting is only valid for that window.
To fix it so you can just run EzIDE from windows explorer or from a shortcut the path needs added from the Windows Environment Variables dialog.
On Windows 7:
Control Panel > System > Advanced system settings>Advanced Tab>Environment Variables Button.
Select and edit the path under the system variables section.
Chris Wardell
G / G Propeller Platform
USB Propeller Plug
I have trouble on Odroid U3, with the compiler I need, I have tried with gcc and g++ without success. It's an ARM you know.
Ken Gracey
Perhaps not, especially if the names are descriptive like Simple IDE for C and Simple IDE for Spin. Allow them to take different forks due to design requirements, but they'll both remain simple, open, and accessible to many operating systems.
Ken Gracey
Also, let's not even get into the discussion that SimpleIDE is hardly Simple.
Our requirements are to have satisfied customers, and at first glance it looks like Steve's requirements achieve that goal.
Ken Gracey
He had another idea for the product about 6 months ago: Spin Inside
One way to think of it:
"It can be Spin-Inside, C-Inside, PropBasic-Inside, or something else inside, but it's always a Propeller inside."
It will complain about missing .dll files if you try to run any standalone .exe files you create. To stop that, you need to update the PATH in your system environment variables to include: C:\Qt\Qt5.2.1\5.2.1\mingw48_32\bin
If you aren't sure how to do that, Chris Wardell tells you how to do that here.
I didn't try compiling any Spin programs since I don't have OpenSpin or the Propeller loader on this PC (I need to grab the new SimpleIDE) and it is late. I'm sure that will work based on my Mac experiences earlier today.
Two down (Win 7 and OS X), one to go (Linux)!!
I liked Propeller IDE better too. However, aren't we supposed to be doing real work to improve this program whatever it is called rather than arguing about the name?
At least "Propeller IDE" tells you what it is succinctly. "Spin Inside" is an obscure insider joke that sounds a bit rude.
Now, I get why it is a trip up. Most environments write to storage, then compile. Prop Tool does not.
Here is why I like build from RAM:
If one is using source control, writing before building makes a lot of sense. There is the local copy, working copy at any time, and there is the last commit, or sync.
In this use case, it's perfectly reasonable to pull, build to verify, then change. If change makes sense, return changes to repository, and if it's a good one, like merc or git, tag, etc... leaving everything consistent. Others can pull your changes, or ignore them and pull as some date, change set, tag, whatever.
Now, if you are not using source control, things are different.
Two sub cases:
1. User understands about revisions and does the work to maintain them locally, using a file scheme
2. User does not understand this.
In case 1, open top, build to verify, perform edit and save as on all dependent files, build again to verify, then change.
To avoid the hassle, changes can be in open tabs, user commits by saving, building as needed, until a new state is reached, in which case everything is saved. If user makes ugly error, close, re open file, build again.
In case 2, user will very likely archive data, or work from an archive. The working copy is the working copy. Build from RAM may be useful to them, maybe not. Due to the unmanaged nature of things, it is most friendly to modify program, build and run and repeat, re opening the file to return to the known working state.
In both cases, it's very good for quick tweaks, or experiments that may not warrant a save. An example would be understanding something like gr.setup in the default graphics library on P1. Change it, run it, change it, run it, etc... until the desired result is obtained. Save it then.
Personally, I would love to someday see a transparent github, or google code option where the user doesn't even worry about anything other than the name and revision. I realize this is outside the scope of this project too. I'm not asking, just highlighting what I think would really help get people away from files and into managed thinking, based on my many years doing the same in the MCAD realm, where the problem is equally difficult, and "build from RAM" serves the same workflow purpose as it does here.
At the least, having this be an option would be nice. Of course it would also be nice to just have the management built in too. And have users get it. Someday
Summary: When build from RAM is in play, a user can test, learn, explore without breaking anything. Just don't save and attempt it as many times as they need / want to, no worries. If we can't build from RAM, the user must commit a change to the working copy in order to see it go, and recovering from that takes understanding they may not have. If this is about the same kinds of productivity as the Prop Tool, build from RAM is a part of that package.
I'm confused. You seriously disagree with a point about "compile the currently open tab" vs "always compile a designated top object" and then give a pros and cons argument about "compile from RAM" or "save to file then compile".
Recently I have been using the Sublime text editor. It has what I think is a nice feature in that what is on disk is always in sync with what you see in the editor. This is nice because if the thing crashes or is otherwise shut down abruptly when you start it up again there is all your work just as you left it. No lost edits and no messing with an editors back up files like with VIM. Also, if the file you have open is changed by some other editor or process at the same time the changes immediately reflect in your open view. No multiple conflicting versions live at the same time.
Of course I would not want to work without git for revision management now a days, given that it is so quick and easy.
Re: GIT. I have sometimes thought that there should be a way to use git without having to use git. If you see what I mean. It should be made transparent. Imagine, for example, that every time you hit "save" or close the editor a new git revision was made and committed and tagged. The revisions tag could just be an advancing number or perhaps the date/time. A commit comment would optional, perhaps a dialog box on save would prompt for some comment to be input. Then when the users messes up his code with his latest experiment he could just hit a "back" button which would load up the previous revision. Repeatedly hitting "back" would step you back further in time. A "forward" button would step your forwards in time.
There we have it, simple but effective revision control. Rather like the good old days of the VMS operating system which would keep multiple versions of files automatically for you.
One can use git from within an application using libgit, it is not necessary to use the command line interface or a GUI tool. So this sort of thing should be possible.
As for "compile current open" vs "compile top object" I'm not fussy.