I think we will not get a bugfix for qt4 too soon. http://bugreports.qt.nokia.com/browse/QTBUG-18038
The only chance seems to be not to use QTextStream for reading the file but to do it low level with QFile and successive read(1) like in the good old days.:frown:
Or discard the automatic support for old style mac files and leave it to the user to convert them - this would be IMO the worst solution.
Addendum: If you replace line 48 in file spineditor.cpp
if (!file.open(QFile::ReadOnly | QFile::Text)) {
with
if (!file.open(QFile::ReadOnly)) {
it seems to work, but I am not sure if that introduces other side effects.
Making some progress. Written a new, much faster lexical scanner for SPIN code. This is going to replace separate scanners used in different places (method names extraction, pre-processing, syntax highlighting), so only one pass of scanning is done when code changes.
Also, basic autocompletion is done - see attachment. Now working on context-aware autocompletion, so for example in DAT block autocompletion list would not include names from VAR blocks
Fantastic. I love this.
I'd like to get it compiled and running on my ARM board http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55
Only trouble is BST does not run there. It might be possible to get the HomeSpun comiler running under Mono though. If PZST will ever support the use of HomeSpun...
Not a big trouble, I think. Basic command-line options are the same, possibly there are differences in list file format and error reporting. But this is not a priority
Interested. Why does every one use Qt? There are much better widget toolkits out there, if you must use a cross platform widget toolkit. As example; FLTK, X, Zune, etc... Qt is one of the most bloated.
It allows me to do things. I have devoted some time to learn it. The results are satisfactory. I have no time to learn all those toolkits available. Is that enough?
Interested. Why does every one use Qt? There are much better widget toolkits out there
No there aren't
FLTK is probably faster and lighter, it's also a lot, well, less.
zune does not exist for Linux as far as I can tell. Never heard of it before.
X is not a tool kit as such. A raw X application is not cross platform unless your platform has X.
Yes Qt is somewhat huge and perhaps not has fast as we'd like but it does run on mobile phones and it does run on my credit card sized ARM boards. It is at least very cross-platform. Qt is not just for graphical widgets, it provides pretty much cross-platform everything.
Up until now it had excellent support from a huge company, Nokia, and others. Sadly Nokia has gone all Windows Phone so I hope Qt survives the chaos.
A raw X application is not cross platform unless your platform has X.
Yes this is true. Though I am not aware of a commonly used platform for which X is not available. There are ports of X11 to almost everything including: Amiga, TOS+MiNT, Windoze, M$-DOS, Mac OS (from Mac OS 7.1 up), almost all unixons, and many more.
Yes Qt is somewhat huge and perhaps not has fast as we'd like but it does run on mobile phones and it does run on my credit card sized ARM boards. It is at least very cross-platform. Qt is not just for graphical widgets, it provides pretty much cross-platform everything.
Ok fair enough, I can see the advantage of having more than just a Widget Toolkit cross platform.
It allows me to do things. I have devoted some time to learn it. The results are satisfactory. I have no time to learn all those toolkits available. Is that enough?
I did not mean to change what you are doing. Also I apologize if my statement caused a personal reaction.
I was just voicing my personal dislike for toolkits that are bloated to the point that you need a 'modern' system to use them. I have always been about optimizing things to unreasonable extremes, to the point that when I code in C I keep in mind how the particular C compiler being used does its optimizations so that I may write my code in such a way to best facilitate good optimization by that compiler (why do we want faster computers if we are just going to slow them down by bloated, not well optimized code).
Those interested to try new features (code completion and call tips) - checkout revision 22. Also, syntax highlighting is now much faster - no visible delay when jumping from start to end of just-loaded file. You will need re2c to compile PZST.
I am starting to work on improved search engine. After this stage is complete - first binary release will be rolled.
I had to disable it for now, it is causing troubles with editing in folded areas. Not sure if this is scintilla's glitch or problem of my implementation.
I'm running into a compile error. termios.h on OS X 10.6 only defines baud rate constants up to B230400.
Currently, serial port is only used for communication with Propeller's bootloader, at 115200. So in eserialport_posix.cpp, you can remove all those case stements that refer undefined constants.
Fingers crossed, waiting for result of compilation under OSX
Thanks to some help from Andrey in private messages I'm getting very close to successfully compiling. Here's where things stand.
First, Qt Creator couldn't find re2c. It's in /opt/local/bin which is in my PATH, but Qt Creator isn't seeing the PATH that's created in .bash_profile or in .bashrc. So I manually added /opt/local/bin to Qt Creator's search path.
Then it couldn't find libqscintilla2.a. I'm not sure where the install process put the Qt sdk. The executables, examples, etc. are in various directories under /Developer. I tried those and /usr/local/Qt4.7 and none of them worked. Andrey suggested using "make install" to have the library magically moved to the correct location. That turned out to be /Library/Frameworks.
Now the linking process fails with
Undefined symbols:
"PZST::SpinCodeLexer::scan(char*, char*, char**)", referenced from:
PZST::SpinPreprocessor::findObjects(QString, QStringList, QStringList&, QStringList&)in spinpreprocessor.o
PZST::SpinCodeParser::parseCode(QString) in spincodeparser.o
ld: symbol(s) not found
I should have left work an hour ago. I need to leave now. I'll try to work on this more over the next couple days.
Steve, most likely that is because it did not catch up changes to spincodelexer.cpp due to failures to launch re2c. Try to delete spincodelexer.cpp (or select "Clean All" from Qt Creator's "Build" menu), then rebuild pzst
Sorry off topic:
Oh unlucky you must be . I work 6 feet from where I sleep (and 2 feet from my computer), so that I never 'need to leave' work .
I did that for about ten years, but I had a separate office in the house so I still "left" work. But that dried up so now I have to drive fifteen minutes to work. The 30-second commute was definitely better, but I do enjoy my current job.
Steve, most likely that is because it did not catch up changes to spincodelexer.cpp due to failures to launch re2c. Try to delete spincodelexer.cpp (or select "Clean All" from Qt Creator's "Build" menu), then rebuild pzst
Success! Pzst compiles and runs. Where does pzst look for bstc.osx? It's in my path, but I'm getting the "Failed to start compiler" message. [Edit: I tried renaming bstc.osx to bstc but still get the error.]
Unfortunately, I won't be able to hook up a Propeller to test until this weekend. Tomorrow night I'm going to the Parallax meetup in Rocklin and Friday night is promised to my wife.
Comments
Result: The whole file is loaded as a single line!!
What on earth is going on?
http://bugreports.qt.nokia.com/browse/QTBUG-18038
The only chance seems to be not to use QTextStream for reading the file but to do it low level with QFile and successive read(1) like in the good old days.:frown:
Or discard the automatic support for old style mac files and leave it to the user to convert them - this would be IMO the worst solution.
Addendum: If you replace line 48 in file spineditor.cpp
if (!file.open(QFile::ReadOnly | QFile::Text)) {withif (!file.open(QFile::ReadOnly)) {it seems to work, but I am not sure if that introduces other side effects.Parser and highlighter rely on \n as line separator, so this is not a good solution
I made a comment on your issue in google code which avoids that by replacing the non LF end of lines consistently.
http://code.google.com/p/pzst/issues/detail?id=1
Also, basic autocompletion is done - see attachment. Now working on context-aware autocompletion, so for example in DAT block autocompletion list would not include names from VAR blocks
Stay tuned - first release is coming soon
Autocompletion now works for methods and constants in objects. Also, call tips are implemented
I'd like to get it compiled and running on my ARM board http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55
Only trouble is BST does not run there. It might be possible to get the HomeSpun comiler running under Mono though. If PZST will ever support the use of HomeSpun...
Not a big trouble, I think. Basic command-line options are the same, possibly there are differences in list file format and error reporting. But this is not a priority
No there aren't
FLTK is probably faster and lighter, it's also a lot, well, less.
zune does not exist for Linux as far as I can tell. Never heard of it before.
X is not a tool kit as such. A raw X application is not cross platform unless your platform has X.
Yes Qt is somewhat huge and perhaps not has fast as we'd like but it does run on mobile phones and it does run on my credit card sized ARM boards. It is at least very cross-platform. Qt is not just for graphical widgets, it provides pretty much cross-platform everything.
Up until now it had excellent support from a huge company, Nokia, and others. Sadly Nokia has gone all Windows Phone so I hope Qt survives the chaos.
Ok fair enough, I can see the advantage of having more than just a Widget Toolkit cross platform.
I did not mean to change what you are doing. Also I apologize if my statement caused a personal reaction.
I was just voicing my personal dislike for toolkits that are bloated to the point that you need a 'modern' system to use them. I have always been about optimizing things to unreasonable extremes, to the point that when I code in C I keep in mind how the particular C compiler being used does its optimizations so that I may write my code in such a way to best facilitate good optimization by that compiler (why do we want faster computers if we are just going to slow them down by bloated, not well optimized code).
Well, all the world is spinning around personal reactions, personal preferences, personal wishes
I am starting to work on improved search engine. After this stage is complete - first binary release will be rolled.
Currently, serial port is only used for communication with Propeller's bootloader, at 115200. So in eserialport_posix.cpp, you can remove all those case stements that refer undefined constants.
Fingers crossed, waiting for result of compilation under OSX
First, Qt Creator couldn't find re2c. It's in /opt/local/bin which is in my PATH, but Qt Creator isn't seeing the PATH that's created in .bash_profile or in .bashrc. So I manually added /opt/local/bin to Qt Creator's search path.
Then it couldn't find libqscintilla2.a. I'm not sure where the install process put the Qt sdk. The executables, examples, etc. are in various directories under /Developer. I tried those and /usr/local/Qt4.7 and none of them worked. Andrey suggested using "make install" to have the library magically moved to the correct location. That turned out to be /Library/Frameworks.
Now the linking process fails with
Undefined symbols: "PZST::SpinCodeLexer::scan(char*, char*, char**)", referenced from: PZST::SpinPreprocessor::findObjects(QString, QStringList, QStringList&, QStringList&)in spinpreprocessor.o PZST::SpinCodeParser::parseCode(QString) in spincodeparser.o ld: symbol(s) not foundI should have left work an hour ago. I need to leave now. I'll try to work on this more over the next couple days.
Same thing here
I did that for about ten years, but I had a separate office in the house so I still "left" work. But that dried up so now I have to drive fifteen minutes to work. The 30-second commute was definitely better, but I do enjoy my current job.
Success! Pzst compiles and runs. Where does pzst look for bstc.osx? It's in my path, but I'm getting the "Failed to start compiler" message. [Edit: I tried renaming bstc.osx to bstc but still get the error.]
Unfortunately, I won't be able to hook up a Propeller to test until this weekend. Tomorrow night I'm going to the Parallax meetup in Rocklin and Friday night is promised to my wife.