Roy committed the background coloring tonight. Thanks Roy!
The spin autocompleter (spinsense?) has also been updated.
Next up:
Point to line number in source for compile errors.
Add the zip diffs from Dennis (already in hand).
Add Find/Replace diffs from Dennis when they're ready.
Should be able to make some end user install packages early next week.
I'm getting this white banding between each line when I use either of the Parallax fonts unless I use a very small size (8). Doesn't happen with Courier font:
I just built on Win7, no banding here with either font. Didn't expect any since Win7 is used by Roy. I probably won't be able to test on Mac until tomorrow at the earliest.
It looks reel good.
I pressed my Beanie and it could tell I had a P1 connected and something else.....my DE0. The Propeller detection appears to be working well on Windows. I can connect and disconnect my Prop and it recognize dboit hactions repeatedly.
I couldn't comment on the tab switching speed with large projects because I don't have any large projects!
It's looking really great....except it doesn't recognize my P2 (yet)!
I just built on Mac OSX 10.9.2 and saw banding until you get to a certain size on the Parallax font (I don't have Parallax2 installed)
I played with some other fonts some have banding on some sizes, some have no banding. Courier has on banding that I could see but Courier New had banding on some sizes.
The way the background coloring works is using a feature of Qt. So that banding is a bug in the Mac version of Qt. Do you see it when you select a block of text also?
I'm not totally happy with how it does the coloring, and may end up overriding QPlainTextEdit's paint code in order to do it better (and potentially add more, like the gray indent level guide thingies).
Heater, just to be sure, are you building release or debug? I have noticed it being a touch slower with bigger spin files, but not terribly slow. It is doing a lot of reparsing of stuff when switching tabs.
I just did a release build. Can't say I notice much difference in speed. When switch back to a tab with a lot of methods it's about 4 seconds. Longer than it takes to compile the whole project!
I just did a release build. Can't say I notice much difference in speed. When switch back to a tab with a lot of methods it's about 4 seconds. Longer than it takes to compile the whole project!
Yikes, I've never seen it take anything close to that long. How many functions are in that file you are switching to?
The slowness I was seeing was where it would take a couple hundred milliseconds sometimes on some large files I have.
I'm playing with msrobot's Server_W5100_RTC program. There are 322 PUBs and PRIs (according to grep and wc). Perhaps 4 seconds is an exaggeration. Longer than it takes to compile everything anyway.
Admittedly I'm using an old amd 64 machine here but it that a slow a slow old girl. Using this on a Rasperry Pi will be another 8 or ten times slower.
I have a simple parser in JavaScript here that pulls out the same PUB/SUB signatures and locations in a lot less than a second
I was wondering about those panels on the right hand side:
a) It seems that when you have a tab open the lower panes shows all PUBs and SUBs lower down the object tree.
There are a lot of methods listed that you cannot reach from the current file as they are private or more than one level deep. This seems unnecessary.
b) The tree view at the to changes to reflect the tree starting from the currently open tab. Perhaps it should always show the tree from the top down so you know where you are.
Heater,
I had a similar idea about "always showing from the top down" but currently there's no top object stuff. Until then, it treats each file you have in focus as the top, essentially.
The parsing that's in there now will eventually be replaced by the compiler when it gets integrated. Steve is still working in there if I recall correctly, so it'll probably get better soon.
I'm sure the method browser is taking lots of time to load.
Strictly speaking it is an unnecessary feature especially just for loading a file into the GUI. It should only be populated when required. There are a couple of alternatives to do it right now.
Roy had mentioned making the method browser available as a tool-bar. We are adding a tool-panel to the bottom of the IDE for doing search/replace (not complete yet). It is reasonable to add a method browser in a similar way, and it could be hidden until someone wanted it. The other option is to make a +/- tree element for each file on the left side. I'm more in favor of adding the hidden browser at the moment. Adding it to the top of the editor, just under the tab may be better because it is a per-file thing.
Right now i'm struggling with some zip file issues. I have the changes isolated so it won't be too disruptive. Most likely I'll just commit what I have and finish it later.
Regardless, I expect to not be very productive today because of another huge distraction.
If I have a bunch of spin files open and a few in a library folder then it might be nice to see all the methods available as I'm typing now. Only the methods in the current spin file and any PUBs of files I have put in OBJ. In my current scope that is.
That's the stuff that auto complete should offer.
So much so I started making one for openspin in he browser.
Propeller IDE converted my ASCII encoded Spin sources to UTF16 !!
I might never have known or cared but last night I was hacking away on my parser. It's a JavaScript thing that finds all sub-objects required of a Spin file and all the PUPs and PRIs in the sources. Recursively for the whole program. Just like in Propeller IDE but an order of magnitude faster
It was late and I was getting tired and just as everything was working fine it broke. Desperately I thrashed around trying to find that last change I made that broke everything. I got more tired and stressed and gave up.
This morning I remembered I had played with PropellerIDE at some point. Sure enough it had corrupted my Spin sources and broke my parser !
You parser should handle any of ASCII, UTF-8, or UTF-16 inputs. Spin source will be in any of those commonly. PropTool saves everything in UTF-16. OpenSpin will read any of them also.
If I open a document in some word processor and it saves it to a different format, say DOCX instead of the original RTF, then that is a corruption of my document. Even if the content is somehow the same. Perhaps my other tools cannot handle it.
Strangely when I throw those same spin sources at openspin in the browser from a simple node.js server it can handle ASCII, UTF-8 and UTF-16 (Well actually UCS2) and I don't have to do anything special to deal with that,
The JS in the browser, or my parser, knows nothing of any of this encoding. Everything is just a JS string. Which is actually UCS2 under the hood which means it can't really handle unicode properly.
Unicode should be banned.
I can open files as byte buffers and check for UTF-8/16 and then convert those buffers to sting with the right encoding options I guess. Blech...
Steve,
You can't just blanketly save the file in the format it was opened as.... What happens if they open an ASCII file, but then add a bunch of parallax font characters to draw a schematic or whatever, and then save it, it should save in unicode to retain the drawing, but if you force it back to ascii you will destroy their file.
I agree it could attempt to save it in the original form if possible, but if not then either upgrade to unicode by default or throw up a prompt saying they need to either save as unicode or lose information in their file.
Heater, I'm amazed the JavaScript doesn't just automatically work with whatever unicode you give it (ASCII is just utf-8 without the BOM character and no characters above 127, which is legal).
Steve,
You can't just blanketly save the file in the format it was opened as.... What happens if they open an ASCII file, but then add a bunch of parallax font characters to draw a schematic or whatever, and then save it, it should save in unicode to retain the drawing, but if you force it back to ascii you will destroy their file..
Qt has some stream decoders in it. I'm looking at that closer. It would be easy if the whole world was Spinny of course But it ain't, and I'm happy to deal with it.
Heater has mentioned liking the method browser as is. Honestly though, it would be best to move on to a per-file browser. I'll probably start moving that way soon.
I decided to go back to the SimpleIDE methodology for load/save. Basically, it goes like this:
On loading a file, if the UTF-16 Byte Order Mark exists at the beginning of a file, then the file will be treated as UTF-16, and any file save will be as UTF-16. If the Byte Order Mark does not exist, then the file will be treated as UTF-8. Since UTF-8 is a superset of ASCII, any ASCII file will be preserved in the original form. If any special characters are added to the file, they are saved as part of UTF-8 format. Any new files will be saved as UTF-16 (this is a little different from SimpleIDE since it tries to deal with UTF-8 exclusively).
You may also notice not that the file change marker (*) in a tab goes away on save now.
Also if a save fails for some reason (can't open file for writing), the program will notify with a message box.
These changes have been pushed. Please pull, update, build, and test.
Comments
Seems we are getting all the nice bits of PropTools coloring.
Please let me know when it is ready for prime time testing (too busy to read back thru all the posts) - maybe a change in the title would do it.
The spin autocompleter (spinsense?) has also been updated.
Next up:
Add the zip diffs from Dennis (already in hand).
Add Find/Replace diffs from Dennis when they're ready.
I'm getting this white banding between each line when I use either of the Parallax fonts unless I use a very small size (8). Doesn't happen with Courier font:
This is on Mac OS X (10.9).
dgately
Awful slow changing tabs with a large project load though.
It looks reel good.
I pressed my Beanie and it could tell I had a P1 connected and something else.....my DE0. The Propeller detection appears to be working well on Windows. I can connect and disconnect my Prop and it recognize dboit hactions repeatedly.
I couldn't comment on the tab switching speed with large projects because I don't have any large projects!
It's looking really great....except it doesn't recognize my P2 (yet)!
I see that the older version of the Parallax font is scaling properly now as opposed to when I made post #321.
http://forums.parallax.com/showthread.php/153921-Open-Propeller-Project-3-Propeller-IDE?p=1245679&viewfull=1#post1245679
C.W.
Edit: I tried out my two new quickstart boards and they were both detected and worked fine.
I played with some other fonts some have banding on some sizes, some have no banding. Courier has on banding that I could see but Courier New had banding on some sizes.
The parallax.ttf is still broken. I just skipped the bad sizes in the zoom in/out feature. You can still pick them from the font dialog.
Regarding performance with big files: The source browser is the main culprit, and I'm thinking of changing the way it works ... not today though.
I'm not totally happy with how it does the coloring, and may end up overriding QPlainTextEdit's paint code in order to do it better (and potentially add more, like the gray indent level guide thingies).
Heater, just to be sure, are you building release or debug? I have noticed it being a touch slower with bigger spin files, but not terribly slow. It is doing a lot of reparsing of stuff when switching tabs.
Yes, I still get banding when selecting text.
Banding/non-banding is hit & miss for all fonts at different sizes. I'm not able to figure put a pattern for the non-banded occurrences.
dgately
You found a bug in my section start detection stuff.
Yikes, I've never seen it take anything close to that long. How many functions are in that file you are switching to?
The slowness I was seeing was where it would take a couple hundred milliseconds sometimes on some large files I have.
I'm playing with msrobot's Server_W5100_RTC program. There are 322 PUBs and PRIs (according to grep and wc). Perhaps 4 seconds is an exaggeration. Longer than it takes to compile everything anyway.
Admittedly I'm using an old amd 64 machine here but it that a slow a slow old girl. Using this on a Rasperry Pi will be another 8 or ten times slower.
I have a simple parser in JavaScript here that pulls out the same PUB/SUB signatures and locations in a lot less than a second
I was wondering about those panels on the right hand side:
a) It seems that when you have a tab open the lower panes shows all PUBs and SUBs lower down the object tree.
There are a lot of methods listed that you cannot reach from the current file as they are private or more than one level deep. This seems unnecessary.
b) The tree view at the to changes to reflect the tree starting from the currently open tab. Perhaps it should always show the tree from the top down so you know where you are.
I had a similar idea about "always showing from the top down" but currently there's no top object stuff. Until then, it treats each file you have in focus as the top, essentially.
The parsing that's in there now will eventually be replaced by the compiler when it gets integrated. Steve is still working in there if I recall correctly, so it'll probably get better soon.
Strictly speaking it is an unnecessary feature especially just for loading a file into the GUI. It should only be populated when required. There are a couple of alternatives to do it right now.
Roy had mentioned making the method browser available as a tool-bar. We are adding a tool-panel to the bottom of the IDE for doing search/replace (not complete yet). It is reasonable to add a method browser in a similar way, and it could be hidden until someone wanted it. The other option is to make a +/- tree element for each file on the left side. I'm more in favor of adding the hidden browser at the moment. Adding it to the top of the editor, just under the tab may be better because it is a per-file thing.
Right now i'm struggling with some zip file issues. I have the changes isolated so it won't be too disruptive. Most likely I'll just commit what I have and finish it later.
Regardless, I expect to not be very productive today because of another huge distraction.
If I have a bunch of spin files open and a few in a library folder then it might be nice to see all the methods available as I'm typing now. Only the methods in the current spin file and any PUBs of files I have put in OBJ. In my current scope that is.
That's the stuff that auto complete should offer.
So much so I started making one for openspin in he browser.
OK Who did it? Stand up!
Propeller IDE converted my ASCII encoded Spin sources to UTF16 !!
I might never have known or cared but last night I was hacking away on my parser. It's a JavaScript thing that finds all sub-objects required of a Spin file and all the PUPs and PRIs in the sources. Recursively for the whole program. Just like in Propeller IDE but an order of magnitude faster
It was late and I was getting tired and just as everything was working fine it broke. Desperately I thrashed around trying to find that last change I made that broke everything. I got more tired and stressed and gave up.
This morning I remembered I had played with PropellerIDE at some point. Sure enough it had corrupted my Spin sources and broke my parser !
You parser should handle any of ASCII, UTF-8, or UTF-16 inputs. Spin source will be in any of those commonly. PropTool saves everything in UTF-16. OpenSpin will read any of them also.
If I open a document in some word processor and it saves it to a different format, say DOCX instead of the original RTF, then that is a corruption of my document. Even if the content is somehow the same. Perhaps my other tools cannot handle it.
Strangely when I throw those same spin sources at openspin in the browser from a simple node.js server it can handle ASCII, UTF-8 and UTF-16 (Well actually UCS2) and I don't have to do anything special to deal with that,
The JS in the browser, or my parser, knows nothing of any of this encoding. Everything is just a JS string. Which is actually UCS2 under the hood which means it can't really handle unicode properly.
Unicode should be banned.
I can open files as byte buffers and check for UTF-8/16 and then convert those buffers to sting with the right encoding options I guess. Blech...
Sorry about the UTF-16 stuff. I just assumed that was the Spinny thing to do.
The iconv command in linux can change things from UTF-16 to ASCII.
I'll update the PropellerIDE code to save as whatever it was opened as.
iconv is my old friend in Spiny land
I just noticed that if PropellerIDE is saving to a file it does not have permissions to write to it fails silently.
Oops. Thanks for noting this.
You can't just blanketly save the file in the format it was opened as.... What happens if they open an ASCII file, but then add a bunch of parallax font characters to draw a schematic or whatever, and then save it, it should save in unicode to retain the drawing, but if you force it back to ascii you will destroy their file.
I agree it could attempt to save it in the original form if possible, but if not then either upgrade to unicode by default or throw up a prompt saying they need to either save as unicode or lose information in their file.
Heater, I'm amazed the JavaScript doesn't just automatically work with whatever unicode you give it (ASCII is just utf-8 without the BOM character and no characters above 127, which is legal).
Qt has some stream decoders in it. I'm looking at that closer. It would be easy if the whole world was Spinny of course
Heater has mentioned liking the method browser as is. Honestly though, it would be best to move on to a per-file browser. I'll probably start moving that way soon.
I decided to go back to the SimpleIDE methodology for load/save. Basically, it goes like this:
On loading a file, if the UTF-16 Byte Order Mark exists at the beginning of a file, then the file will be treated as UTF-16, and any file save will be as UTF-16. If the Byte Order Mark does not exist, then the file will be treated as UTF-8. Since UTF-8 is a superset of ASCII, any ASCII file will be preserved in the original form. If any special characters are added to the file, they are saved as part of UTF-8 format. Any new files will be saved as UTF-16 (this is a little different from SimpleIDE since it tries to deal with UTF-8 exclusively).
You may also notice not that the file change marker (*) in a tab goes away on save now.
Also if a save fails for some reason (can't open file for writing), the program will notify with a message box.
These changes have been pushed. Please pull, update, build, and test.
Currently I have webserver_w5100 open and the method browser has more entries in it than one can deal with.
Certainly PRI methods of sub objects don't need to be shown, at least by default, I cannot call them fro here.
Similarly sub-sub-objects need not be shown.
Having methods in sorted order would be nice.