I had to prepend the path to echo because the built-in version doesn't accept the -n option.
The compile process currently doesn't update the copy of version.h in the development directory, only in the PZST-build-desktop directory. Is that intentional?
Updated search engine is now functional. The only final touch left is to make it to use sub-expressions from search query in replacement strings. When it is done, I'll start building first binary release. I will be making Windows installer and Debian (and possibly Ubuntu) package. I am also hoping for help from SSteve in making OS X binary.
BTW - Steve, I have removed all that version.h stuff - it's not worth the troubles.
I'll be happy to make the OS X binary. Qt has a tool called macdeployqt that copies the Qt frameworks into the application bundle and creates a dmg file for distribution. I'll give it a try and see if it makes a program that I can run on my Macs that don't have Qt installed.
In my version of spincompiler.cpp I have the line
QString altExe = "/usr/local/bin/bstc.osx";
because QProcess is still not using my entire search path to look for the bstc executable.
The Autocomplete key command is back to Command+Space and that won't work on the Mac.
The bundle identifier for the program is "com.yourcompany.pzst". So PZST's preferences are stored in ~/Library/Preferences/com.yourcompany.pzst.plist. It would be best to have "yourcompany" replaced with a real domain name. I've been searching the Qt documentation but haven't found out how to change that yet.
I still have to use conditional compilation to remove the undefined baud rate symbols in eserialport_posix.cpp in order to compile. Here's a diff of my version: eserialport_posix.cpp.diff.zip
In order to compile PZST under Archlinux I needed to add '/usr/include/dbus-1.0/' to the INCLUDEPATH. This allows dbus.h to be found.
(opening a new issue on code.google.com failed for me, that's why I report it here).
Today I have successfully built my first Debian package. Windows installer will be done with InstallJammer - I have been using it to deploy Qt applications on Windows. Deployment on OS X is described here : http://doc.qt.nokia.com/latest/deployment-mac.html
The only tasks to complete before first release are the user manual (in progress) and possibly some minor issues on OS X.
I'm getting a linker error in r81. I'm at work and don't have time to troubleshoot right now. I'm posting this just in case it's an easy fix on your end:
Undefined symbols:
"PZST::Preferences::valueChanged(QString, QString, QVariant)", referenced from:
PZST::Preferences::emitValueChanged(QString, QString, QVariant)in pzstpreferences.o
"vtable for PZST::Preferences", referenced from:
PZST::Preferences::~Preferences()in pzstpreferences.o
PZST::Preferences::~Preferences()in pzstpreferences.o
PZST::Preferences::Preferences()in pzstpreferences.o
ld: symbol(s) not found
What version of GCC does PZST require? Will it compile with other C compilers (or if C++ other C++ compilers)? Does it contain any asm? Depending on the answers I would like to port it to Amiga OS, Atari TOS+MiNT, Mac OS (7.1 through 8.5), and (big maybe on this one) GSOS.
What version of GCC does PZST require? Will it compile with other C compilers (or if C++ other C++ compilers)? Does it contain any asm? Depending on the answers I would like to port it to Amiga OS, Atari TOS+MiNT, Mac OS (7.1 through 8.5), and (big maybe on this one) GSOS.
The question is actually not about PZST, but about Qt. Does it work on said systems?
It's always a good Idea to do "Clean project" and "Run qmake" after updating the source
I've been doing a "Clean project". I assumed that took care of the "Run qmake" step, but apparently not because now it compiles. I do get a number of warnings, but I suppose that's to be expected with in-development software.
I tried compiling and running 02-PropForth.spin from the PropForth 4.0a project with PZST. It compiles, but runs into an error while programming the EEPROM. I tried it with bst and it works fine. Can you give it a try under Windows and Linux and see if you run into any problems?
If your target platform has a C++ compiler you can get the Qt sources and recompile them for that platform. After that building PZST would be easy.
However you will probably have a lot of work to do adapting Qt to you targets display system, sorting out keyboard, mouse etc etc.
Andrey:
Thank you for the responce. Unfortunately this means that I will not be doing porting, or learning QT at this time.
The reason that I asked in the way I did is it should be simple to replace most toolkit calls with system native calls IF and only if they (and the rest of the app) are written in a non-OO languages, with a bit more difficulty could for C++ IF no templates were involved.
Of course your problems don't end with getting PZST to run on those platforms.
PZST relies on external programs to compile the Spin and load it to the Prop. Currently BradC's BSTC and BSTL. So first you need working versions of those on your target platforms. Or you need to create your own from scratch. BSTC and BSTL are written in Pascal if I understand correctly so a compatible dialect of Pascal would have to be available for the Platform. BradC has not open sourced either program and is unlikely to have the time and or hardware available to support so many platforms.
Potentially PZST could also use HomeSpun as the compiler/loader. That is written in Java so you would need a Java VM for the target.
Sad fact is that after all these years we still do not have an open source tool chain for the Prop (Excepting the Sphinx compiler that actually runs on the Prop and has some limitations). Happily this situation looks like it will be rectified as part of the efforts going on with "Parallax Semiconductors". I believe Roy Eltham is creating a Spin compiler in C or C++ that is intended to be open sourced.
Sorry yes, C# not Java, I keep making that mistake. Despite the fact that last week I was checking that mono worked on my credit card sized ARM board and was thinking to check how HomeSpun runs there. I'll soon be building PZST for that ARM board so if it could possibly make use of HomeSpun that would be great:)
Anyway, I doubt a mono run time is available for some or all of the platforms under discussion. Perhaps not Java either.
Heater:
I whas only woried about a nice IDE for these OSes that is targeted at the prop languages. As far as BSTC goes I can run an emulator to use the win32 ver with DOS + HX32. As far as BSTL goes, I am going to have to replace it any way.
To last comment:
I have to write a Propeller loader for Mac OS 9.22 because my PC died, and my Macs will not run OS X 10.4 at all. This is alright with me as I do not realy like OS X, I was hoping that Copeland would be succeful, instead.
I tried compiling and running 02-PropForth.spin from the PropForth 4.0a project with PZST. It compiles, but runs into an error while programming the EEPROM. I tried it with bst and it works fine. Can you give it a try under Windows and Linux and see if you run into any problems?
That has been fixed. Common error - variable is not wade enough to hold the value. Before sending binary to bootloader, it is encoded. The resulting array is always bigger than binary - ratio is from 8/5 to 8/3, depending on the ratio of the number of zero and one bits in the binary - so the length of encoded array can exceed 65535 when binary is large enough - and variable storing the encoded array length was 16-bit unsigned. I've replaced it with 32-bit var - works fine now.
After reading this entire thread, I would like to give the binary a try on Windows XP SP3 when you publish it. Will I need a windows binary of Qt to run this?
Most lkely, I will be including the Qt DLLs with the windows distribution (I'll have to check the license) - so the installer will be "all in one", no additional components needed. I've been doing this for Qt applications - but these were private projects, not publicly available
Andrey,
Just found this a few days ago...looks like it's coming together nicely! As a KDE4 user, it'll be nice to have a Qt-based editor. I just checked out r99 though and it fails to build eserialport_nonosx.cpp. It looks like it depends on libhal unconditionally. Was this intended? I know I read a page or three back that you and SSteve were working on the serial port code for OSX, but for Linux I think hal has fallen out of favor, at least with the bigger distros. Whichever direction that goes though, thanks for starting this project!
I tried to build revision 99 on Debian.
That gave me an error about a missing libhal.h. That went away with a quick "apt-get install libhal-dev"
Now I have an error about a missing libdbus.h. Installing Debians libdbus-1-dev does not help as it puts the headers in /usr/include/dbus-1.0/dbus/ where they are not found.
Messing around with that gives me some other missing header error so I have to give up for now.
It looks like it depends on libhal unconditionally. Was this intended?
Jesse - yes. libhal and libdbus are not linked with the application, the headers are only required to build - at runtime, an attempt is made to link those libraries, and if that fails, a fallback method for serial port detection is used, Later I may use another method for serial ports enumeration - I am open to suggestions. But for now that is it.
Attached is a build log showing a failure to find dbus/dbus.h whilst compiling eserialport_nonosx.cpp.
I should mention that my Debian is whatever you get when you start out with an unstable lenny and do a dist upgrade. So it may not be in best condition.
Comments
1) I copied version_tpl.h to the PZST-build-desktop directory
2) I made the following change to src.pro:
I had to prepend the path to echo because the built-in version doesn't accept the -n option.
The compile process currently doesn't update the copy of version.h in the development directory, only in the PZST-build-desktop directory. Is that intentional?
BTW - Steve, I have removed all that version.h stuff - it's not worth the troubles.
In my version of spincompiler.cpp I have the line because QProcess is still not using my entire search path to look for the bstc executable.
The Autocomplete key command is back to Command+Space and that won't work on the Mac.
The bundle identifier for the program is "com.yourcompany.pzst". So PZST's preferences are stored in ~/Library/Preferences/com.yourcompany.pzst.plist. It would be best to have "yourcompany" replaced with a real domain name. I've been searching the Qt documentation but haven't found out how to change that yet.
I still have to use conditional compilation to remove the undefined baud rate symbols in eserialport_posix.cpp in order to compile. Here's a diff of my version: eserialport_posix.cpp.diff.zip
(opening a new issue on code.google.com failed for me, that's why I report it here).
As it states, 'replaceSelectedText' is not declared.
The only tasks to complete before first release are the user manual (in progress) and possibly some minor issues on OS X.
Undefined symbols: "PZST::Preferences::valueChanged(QString, QString, QVariant)", referenced from: PZST::Preferences::emitValueChanged(QString, QString, QVariant)in pzstpreferences.o "vtable for PZST::Preferences", referenced from: PZST::Preferences::~Preferences()in pzstpreferences.o PZST::Preferences::~Preferences()in pzstpreferences.o PZST::Preferences::Preferences()in pzstpreferences.o ld: symbol(s) not foundDo you use any templates (if C++)?
It's always a good Idea to do "Clean project" and "Run qmake" after updating the source
The question is actually not about PZST, but about Qt. Does it work on said systems?
Yes.
I've been doing a "Clean project". I assumed that took care of the "Run qmake" step, but apparently not because now it compiles. I do get a number of warnings, but I suppose that's to be expected with in-development software.
I tried compiling and running 02-PropForth.spin from the PropForth 4.0a project with PZST. It compiles, but runs into an error while programming the EEPROM. I tried it with bst and it works fine. Can you give it a try under Windows and Linux and see if you run into any problems?
Here's the page with the download link:
http://code.google.com/p/propforth/downloads/detail?name=Propforth4.0a-20101218.zip
If your target platform has a C++ compiler you can get the Qt sources and recompile them for that platform. After that building PZST would be easy.
However you will probably have a lot of work to do adapting Qt to you targets display system, sorting out keyboard, mouse etc etc.
Thank you for the responce. Unfortunately this means that I will not be doing porting, or learning QT at this time.
The reason that I asked in the way I did is it should be simple to replace most toolkit calls with system native calls IF and only if they (and the rest of the app) are written in a non-OO languages, with a bit more difficulty could for C++ IF no templates were involved.
Of course your problems don't end with getting PZST to run on those platforms.
PZST relies on external programs to compile the Spin and load it to the Prop. Currently BradC's BSTC and BSTL. So first you need working versions of those on your target platforms. Or you need to create your own from scratch. BSTC and BSTL are written in Pascal if I understand correctly so a compatible dialect of Pascal would have to be available for the Platform. BradC has not open sourced either program and is unlikely to have the time and or hardware available to support so many platforms.
Potentially PZST could also use HomeSpun as the compiler/loader. That is written in Java so you would need a Java VM for the target.
Sad fact is that after all these years we still do not have an open source tool chain for the Prop (Excepting the Sphinx compiler that actually runs on the Prop and has some limitations). Happily this situation looks like it will be rectified as part of the efforts going on with "Parallax Semiconductors". I believe Roy Eltham is creating a Spin compiler in C or C++ that is intended to be open sourced.
It's .NET, not Java. On Linux, Mono is used to run .NET apps
Anyway, I doubt a mono run time is available for some or all of the platforms under discussion. Perhaps not Java either.
I whas only woried about a nice IDE for these OSes that is targeted at the prop languages. As far as BSTC goes I can run an emulator to use the win32 ver with DOS + HX32. As far as BSTL goes, I am going to have to replace it any way.
To last comment:
I have to write a Propeller loader for Mac OS 9.22 because my PC died, and my Macs will not run OS X 10.4 at all. This is alright with me as I do not realy like OS X, I was hoping that Copeland would be succeful, instead.
That has been fixed. Common error - variable is not wade enough to hold the value. Before sending binary to bootloader, it is encoded. The resulting array is always bigger than binary - ratio is from 8/5 to 8/3, depending on the ratio of the number of zero and one bits in the binary - so the length of encoded array can exceed 65535 when binary is large enough - and variable storing the encoded array length was 16-bit unsigned. I've replaced it with 32-bit var - works fine now.
Just found this a few days ago...looks like it's coming together nicely! As a KDE4 user, it'll be nice to have a Qt-based editor. I just checked out r99 though and it fails to build eserialport_nonosx.cpp. It looks like it depends on libhal unconditionally. Was this intended? I know I read a page or three back that you and SSteve were working on the serial port code for OSX, but for Linux I think hal has fallen out of favor, at least with the bigger distros. Whichever direction that goes though, thanks for starting this project!
Cheers,
Jesse
That gave me an error about a missing libhal.h. That went away with a quick "apt-get install libhal-dev"
Now I have an error about a missing libdbus.h. Installing Debians libdbus-1-dev does not help as it puts the headers in /usr/include/dbus-1.0/dbus/ where they are not found.
Messing around with that gives me some other missing header error so I have to give up for now.
Heater - can you post the build log? I am building on Debian, and have dbus.h in same location - builds just fine
I should mention that my Debian is whatever you get when you start out with an unstable lenny and do a dist upgrade. So it may not be in best condition.