Were you folding/unfolding or scrolling around the editor at the time?
I've just identified a crash bug in and around that, but I've not found any others yet.
Most important question. Do you think you can reproduce it? (The foldy/scrolly one is a pig to reproduce)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Ok, yeah that sounds like the one. I'm almost ready for a new release so I'll get it tested and out the door tonight. That bug is an ugly one.
Sorry about the hassle.
<edit> ok so this bug is a much deeper symptom of the weird stuff happening with the folding. I'm working on it but it's a very nasty and hard to reproduce so it's gonna take me a couple of days (only I hope). In the mean time, please save periodically or turn the line numbers off. That will disable the code folder.
Another workaround is periodically doing either an unfold all or a fold all. Either one of these clears out the data structure that is getting corrupted and causing things to explode.
The bug manifests itself after a sequence of folding/unfolding blocks in non-sequential order, or adding/deleting lines when blocks surrounding are folded. I'm not quite sure precisely what is getting corrupted yet, but we'll get there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Sorry Brad, another bug. If you have more than one FDTI device and have Auto Select turned on, bst will not find the propeller unless it happens to be the first one. In my case, I had an xBee USB board plugged in and bst was failing to find the propeller. I had to change it to specifically select the correct USB port.
Chuck Rice said...
Sorry Brad, another bug. If you have more than one FDTI device and have Auto Select turned on, bst will not find the propeller unless it happens to be the first one. In my case, I had an xBee USB board plugged in and bst was failing to find the propeller. I had to change it to specifically select the correct USB port.
Yep that is by design.. It's also why I put the manual selection option in the port menu.
I did not really want to hit up each port on the system and spew data at every attached device in search of the propeller.
I do have code to do this, perhaps I should make it an option? "Auto search all attached ports" ?
I kinda feel a bit like its using a hammer to crack a walnut though.
It scans (in this order)
/dev/ttyUSB*
/dev/tty.usbserial*
/dev/ttyS
If you have a device on /dev/tty.usbserial.111 and the propeller is on /dev/tty.usbserial.222 then the propeller won't autodetect.
Do you think I should make it scan all available ports?
I know Propeller tool had a problem locking up bluetooth devices when it did that.
I'm open to suggestions [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Humm... good points, but in my case, there are normally only 2 USB devices, so you have already hit the bad one.
How about this. When you get the error, pop up a dialog box asking me to select one of the ports, then remember that selection and always try that one first. If that fails or it is already in use by another process, ask me again. Also, it would be nice if the saved USB port was associated with the top-level window. My robot used 4 propeller Proto Boards. For communication issues, I need to be working with 2 prop plugs. It would be nice if I could assign a USB device to each so that a Compile & Load would select the correct one. Then when I screw up and try a C&L on a called object, it will ask me which port to use and I can slap my forehead and cancel the Load.
I just reinstalled Ubuntu 8.10 64 bit, on my machine, and when I try to run the latest version of BST, nothing happens, the program will not start. I had it running on my previous install of Ubuntu, but now nothing, anybody having a similar problem?
I poked around and couldn't find the history of your compiler development. Do I understand correctly that the compiler was developed from scratch? If so, does it reliably create the same binary as the Propeller Tool when fed the same source code?
I've had a number of people inquire about a Mac/Linux version of my Coyote-1 device management application (www.openstomp.com) and without a Mac/Linux version of the Propeller Tool available that didn't seem like a very useful thing to work on. I tried out the latest build of your tool on a Mac and it successfully compiled my device's code base (though I haven't yet tested the image it generated, or compared it to the Propeller tool's binary), so it seems like a Mac/Linux option may actually be worth pursuing.
I poked around and couldn't find the history of your compiler development. Do I understand correctly that the compiler was developed from scratch?
Yes, it was developed completely from scratch.
epmoyer said...
If so, does it reliably create the same binary as the Propeller Tool when fed the same source code?
In every instance I've tested so far, yes.. My test suite is over 1600 spin files including everything in the Object exchange, Hydra forum and Hydra CD. Thus far, every generated binary is bit for bit identical to the output of the Parallax compiler. I do have one corner case I know about with chaining round(float( type of things that will give a 1lsb error, but I'm working on it.
epmoyer said...
I've had a number of people inquire about a Mac/Linux version of my Coyote-1 device management application (www.openstomp.com) and without a Mac/Linux version of the Propeller Tool available that didn't seem like a very useful thing to work on. I tried out the latest build of your tool on a Mac and it successfully compiled my device's code base (though I haven't yet tested the image it generated, or compared it to the Propeller tool's binary), so it seems like a Mac/Linux option may actually be worth pursuing.
Again, Great work. Very impressive!
Ta. If the binary it generates is not identical then I'd love a copy of the spin source so I can fix it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Rsadeika said...
I just reinstalled Ubuntu 8.10 64 bit, on my machine, and when I try to run the latest version of BST, nothing happens, the program will not start. I had it running on my previous install of Ubuntu, but now nothing, anybody having a similar problem?
Have you got the 32 bit gtk libraries installed?
Try "ldd ./bst" and see if there are any missing dependencies. Here is my output
Firstly I' m real happy I can program native on Linux and Mac. The code I'm working on is just one file because is mostly assembler (except for the initial cognews), so the file has some 4700 lines. Either with or without syntax highlight the editor feels slow. I type some chars sort of fast and they lag to show; the cursor also moves slowly. This is in an AthlonXP (1.83 GHz), Ubuntu 7.04, with the corresponding blob for the graphics card. (I'm using BST 0.13). Can something be done ? (besides getting a faster computer ?)
Firstly I' m real happy I can program native on Linux and Mac. The code I'm working on is just one file because is mostly assembler (except for the initial cognews), so the file has some 4700 lines. Either with or without syntax highlight the editor feels slow. I type some chars sort of fast and they lag to show; the cursor also moves slowly. This is in an AthlonXP (1.83 GHz), Ubuntu 7.04, with the corresponding blob for the graphics card. (I'm using BST 0.13). Can something be done ? (besides getting a faster computer ?)
thanks,
ALe
Yes, I did something dumb when I built the editor and only realised last week what I did, so it's fixed in the next release (which should be out sometime after saturday)
Sorry about that, but yes the editors performance sucks in those early versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
before you release the next version, here is a little bug I just found:
If I write this:
long (k4_b<<26)+@m_B_cfg_curr+16
or this :
long (k4_b<<26)+16+@m_B_cfg_curr
I get the error message "Expected Spin Instruction, Unique Name, Floating point Constant, etc ". If I rewrite it like this:
long @m_B_cfg_curr+(k4_b<<26)+16
It does not error.
Thanks!
Excellent catch! That would only exhibit itself if the first component of an expression was a parentheses block *and* there was a @ in the expression. Apparently none of my test suite has those conditions [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Another day, another bst release, and this one is 0.14.
Check the top post for changelog as usual, but read on to get more detail on the additional features (of which there are a few).
You can now click on the grey line marking the code-block and the entire block will collapse.
There is now an option for find/replace to search the whole file scope. Find will just loop around when it hits the end, as will replace, whereas replace-all will move the cursor to the top of the file and go from there.
We now have an option to assign individual propeller ports to editor tabs, so I can select a tab and download the right code to the right propeller if I have multiple props connected (ide prefs checkbox). Right-Click->Assign Propeller from inside the editor.
After careful consideration, I decided that being able to assign a port to an editor tab is pretty naff unless we have the ability to make it persistent, so I introduce you to "The Project File". A concept shamelessly ripped of from numerous IDE's from time immemorial (Well, actually Delphi 1 was my first encounter)
The project file is entirely optional, you don't need one and it won't impact you in any way should you choose to shun this option. Having said that, you can create one at any time from your current editor configuration by simply asking to save a project file.
The project file saves :
- What tabs you have open
- What order the tabs are
- Where each editor tab is scrolled to
- What propeller port is assigned to that tab
- What code folds you have active in that tab
If you close the project file, it will close all the tabs you currently have open. Let me re-state that. CLOSE PROJECT, CLOSE ALL TABS!
Now if you close the editor, it will prompt you to save all the current tabs contents, then it will ask you to save the project. You don't have to do this, you can tell it to not save just the same as you can decline to save an editor file.
There is an option in the ide preferences that will, when enabled, re-open the project you had open when you last closed the ide. If you saved everything as you were closing, then you will find your workspace re-opened precisely as you left it.
The project menu has a recent projects menu, just like recent files, and you can use this to jump between projects in completely different locations. When you open a new project, the current project is entirely closed (as are all its tabs) and the new one opened.
There is now an option to save the recovery file on a timed basis in addition to the auto-recover-save prior to each compile. Settable in minutes between 2 and 120 (see the ide prefs for details) Remember, the auto-recover-save is not saving your edited files to disk, merely saving a representation of any unsaved files in the editor in case it should crash. bst is the only thing that can read these files back again (and it should do in the event of it being re-started after a crash)
From the "standing on the shoulders of giants" department (read as this is built from Lazarus and FreePascal) we have the line changed indicators (same as delphi, visual studio and numerous other GUIs). It's a new addition to the Lazarus stable and therefore it cost me very little to build in, so there it is (it's also optional).
Pruning some more "low hanging fruit", I've managed to speed up the tokeniser in the compiler again to give an overall speed increase of 30% on the last release. This has also translated into a faster highlighter and more responsive editor (especially on my 400Mhz G4!). An updated and accelerated command line compiler will be forthcoming.
The project support is really new and it might well have usability "issues". Stuff like it asking you to save unsaved tabs twice on close and things like that. You report 'em and I'll fix 'em [noparse]:)[/noparse]
I think I've squashed every bug reported so far, but if I've missed yours please yell loudly.
As always, feedback warmly welcomed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I've started loosing connection to the propeller during upload on a more frequent basis in the last couple releases.
but here is the interesting one I've found...
A few programmers like to use ' and { together. However bst won't see the '} and assume that the brackets are
not being used.
Example: (from HDMF, but Baggers likes to do this too. [noparse]:)[/noparse] )
str+=9
repeat t from 0 to 7
nibble := i & $0000000f
if nibble =< 9
BYTE[noparse][[/noparse]str] := 48 {'0'} + nibble
else
BYTE[noparse][[/noparse]str] := CONSTANT(65 {'A'} - 10) + nibble
str--
i >>= 4
At the {'0'} things start to go haywire, and everything beyond is remarked.
Thanks again for a great program! BST has become my "standard" tool now.
I've started loosing connection to the propeller during upload on a more frequent basis in the last couple releases.
but here is the interesting one I've found...
A few programmers like to use ' and { together. However bst won't see the '} and assume that the brackets are
not being used.
Example: (from HDMF, but Baggers likes to do this too. [noparse]:)[/noparse] )
str+=9
repeat t from 0 to 7
nibble := i & $0000000f
if nibble =< 9
BYTE[noparse][[/noparse]str] := 48 {'0'} + nibble
else
BYTE[noparse][[/noparse]str] := CONSTANT(65 {'A'} - 10) + nibble
str--
i >>= 4
At the {'0'} things start to go haywire, and everything beyond is remarked.
Oh yes, I can see why that occurs. I'll get it fixed. Thanks [noparse]:)[/noparse]
I'll also investigate the comms. I've been making some subtle changes to the serial code to try and make Windows behave better and I'm sure that I've not been paying enough attention to the timing effects on Linux and MacOS. Will look into it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Hey Brad, thanks for posting the new rev with upgraded blockfolding.
One thing I have been experiencing on all pre 14 versions is that quite often the "+" block fold icons ten to lose their place, the sometimes don't fold themselves, and very frequently become erratic. Folding all blocks will reset the issue though, so it is a good work around. (XP)
On the OSX version which I don't use much (yet), I notice that the default highlighter color is very hard to see as the blue is very similar to the highlight color. XP is fine to distinguish the two, but I think the OSX version could use some contrasting measure.
TChapman said...
Hey Brad, thanks for posting the new rev with upgraded blockfolding.
One thing I have been experiencing on all pre 14 versions is that quite often the "+" block fold icons ten to lose their place, the sometimes don't fold themselves, and very frequently become erratic. Folding all blocks will reset the issue though, so it is a good work around. (XP)
All those issues should be fixed in the latest version. There was a serious amount of work went into various ugly bugs in the block folder.
I'd be _really_ interested to hear of any reproducible nasties in it now.
TChapman said...
On the OSX version which I don't use much (yet), I notice that the default highlighter color is very hard to see as the blue is very similar to the highlight color. XP is fine to distinguish the two, but I think the OSX version could use some contrasting measure.
Thanks again.
No worries. I'm thinking about configurable keystrokes and configurable highlighter colours/parameters in the next version or two, so hopefully we can iron out some of the OS specific colour issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Brad, thanks for the new release! Lots of good stuff there.
A couple of bugs so far:
1) The attached file does strange things on the last fold, maybe because it has a commented out PUB routine inside a con section.
2) I have had some trouble with the projects. Once I get it working it works great, but creating a project file the first time has given me trouble. I am still a bit confused about what is happening, more when I understand it more, but you my want to take a look at the save dialog box. Sometimes it defaults to "name-of-the-last-tab-saved.spin", instead of 'something.sprj'
x << 8 complies on a line by itself, but it gives "requires an operator" in the Prop Tool.
The folds are working much better, many times a day prior to 14, the mouse wheel would stop allowing any scrolling past a certain point, fold all would resolve it for a short time but it always came back. No problems now after a few hours on XP.
Chuck Rice said...
Brad, thanks for the new release! Lots of good stuff there.
A couple of bugs so far:
1) The attached file does strange things on the last fold, maybe because it has a commented out PUB routine inside a con section.
The problem there is we have 2 folds beginning on the same line.
con <- is the first level, then {{ <- is the second. The block folder only folds the first available level on the block stack when you click the [noparse][[/noparse]x].
I have to think about how to go about fixing this one. I'm still debating the utility of having {} and {{}} be their own foldable blocks. If I removed that then the problem would go away. I'd rather fix it to properly fold the nested blocks though.
Chuck Rice said...
2) I have had some trouble with the projects. Once I get it working it works great, but creating a project file the first time has given me trouble. I am still a bit confused about what is happening, more when I understand it more, but you my want to take a look at the save dialog box. Sometimes it defaults to "name-of-the-last-tab-saved.spin", instead of 'something.sprj'
Yes, I can see how that happens. I don't change the default filename of the save box when setting it up to save a project file. I'll make sure that is fixed.
I've found one or two other little niggles with the project handling I need to think about also. Easy workaround for that problem is to type in a full filename with the .sprj on the end when saving a project for the first time.
Cheers for the feedback.
One note for linux users if you have more than one ftdi device connected. I've found if you have 2 or more devices on a USB2 hub they can interfere with one another and cause large timeout delays in the linux driver. I work around this by having one on the hub and one connected directly to a root port on the PC. Just something to watch anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
BardC said...
One note for linux users if you have more than one ftdi device connected. I've found if you have 2 or more devices on a USB2 hub they can interfere with one another and cause large timeout delays in the linux driver. I work around this by having one on the hub and one connected directly to a root port on the PC. Just something to watch anyway.
I can confirm this. I thought it was a problem with VMWare but it may have not been. I had a Intronix LogicPort connected to a hub that has the Ale's PropClip. Using the two of them together caused loss of connection from BST to the Propeller. (Linux).
The projects is something I also asked you-know-who , still nothing. Well, I use BST all the time now. Great Work Brad! BST rocks.
BardC said...
One note for linux users if you have more than one ftdi device connected. I've found if you have 2 or more devices on a USB2 hub they can interfere with one another and cause large timeout delays in the linux driver. I work around this by having one on the hub and one connected directly to a root port on the PC. Just something to watch anyway.
I can confirm this. I thought it was a problem with VMWare but it may have not been. I had a Intronix LogicPort connected to a hub that has the Ale's PropClip. Using the two of them together caused loss of connection from BST to the Propeller. (Linux).
Yeah, it took me _ages_ to figure out it was not my software but an "issue" in the linux ftdi driver. I'm trying to get some definite debug info so I can pass the bug upstream and get it fixed. Using two separate root ports makes the problem go away though.
Ale said...
The projects is something I also asked you-know-who , still nothing. Well, I use BST all the time now. Great Work Brad! BST rocks.
Yeah, the project file thing fell out of the need to be able to save which port was allocated to which tab. I do have plans to enhance it further but it looks like I'm going to be moving countries again shortly so I might be confined to bug fixes for a while.
Did the latest revision solve your cursor speed/lag issue? I can't fix the scroll speed or re-paint speed. It's an artifact of the way the font gets painted begin slow under gtk2 (I can't use the normal painting methods as the character width is doing strange things with the Parallax font). I did find a major bug where I was re-painting the entire window each time the cursor moved. That was slowing things down a _lot_.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I was reading about all of the things that are saved in a "Project", and I wonder if you could save object paths in projects as well. I might have one project using a new revision of an object, while another might still use an old revision.
As a Linux user, I have to say you hit the nail on the head with BST. The Propeller was one of the few remaining reasons to keep Windows on my computer. One more gone!
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
I was reading about all of the things that are saved in a "Project", and I wonder if you could save object paths in projects as well. I might have one project using a new revision of an object, while another might still use an old revision.
I have been thinking about having a project specific override for both compiler paths and compiler options (optimisations). I need to think some more about how I might get that to work with the current configuration system. Thanks for the prompt, it's now on the todo list.
Thanks for the kind words, I'm glad you find it usable (notwithstanding the bugs).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Ken Paterson said...
As a Linux user, I have to say you hit the nail on the head with BST. The Propeller was one of the few remaining reasons to keep Windows on my computer. One more gone!
I second that. I'm using OS X and my experiece of programming the Propeller has improved tremendously since I stopped having to use Windows. Now I don't have to go through the extra step of making sure my Prop files on the virtual machine are getting backed up. And now it's so much easier to use Quartz Composer to visual the debug/telemetry data coming off the Prop.
Brad, thanks a lot. You may be wondering how many people use and appreciate your software. I use it every day. I know there's several linux users here, and probably a lot more OS X users than one might think.
Comments
I've just identified a crash bug in and around that, but I've not found any others yet.
Most important question. Do you think you can reproduce it? (The foldy/scrolly one is a pig to reproduce)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Sorry about the hassle.
<edit> ok so this bug is a much deeper symptom of the weird stuff happening with the folding. I'm working on it but it's a very nasty and hard to reproduce so it's gonna take me a couple of days (only I hope). In the mean time, please save periodically or turn the line numbers off. That will disable the code folder.
Another workaround is periodically doing either an unfold all or a fold all. Either one of these clears out the data structure that is getting corrupted and causing things to explode.
The bug manifests itself after a sequence of folding/unfolding blocks in non-sequential order, or adding/deleting lines when blocks surrounding are folded. I'm not quite sure precisely what is getting corrupted yet, but we'll get there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Post Edited (BradC) : 11/24/2008 1:48:09 PM GMT
Yep that is by design.. It's also why I put the manual selection option in the port menu.
I did not really want to hit up each port on the system and spew data at every attached device in search of the propeller.
I do have code to do this, perhaps I should make it an option? "Auto search all attached ports" ?
I kinda feel a bit like its using a hammer to crack a walnut though.
It scans (in this order)
/dev/ttyUSB*
/dev/tty.usbserial*
/dev/ttyS
If you have a device on /dev/tty.usbserial.111 and the propeller is on /dev/tty.usbserial.222 then the propeller won't autodetect.
Do you think I should make it scan all available ports?
I know Propeller tool had a problem locking up bluetooth devices when it did that.
I'm open to suggestions [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
How about this. When you get the error, pop up a dialog box asking me to select one of the ports, then remember that selection and always try that one first. If that fails or it is already in use by another process, ask me again. Also, it would be nice if the saved USB port was associated with the top-level window. My robot used 4 propeller Proto Boards. For communication issues, I need to be working with 2 prop plugs. It would be nice if I could assign a USB device to each so that a Compile & Load would select the correct one. Then when I screw up and try a C&L on a called object, it will ask me which port to use and I can slap my forehead and cancel the Load.
You've done an excellent job on this tool. Kudos!
I poked around and couldn't find the history of your compiler development. Do I understand correctly that the compiler was developed from scratch? If so, does it reliably create the same binary as the Propeller Tool when fed the same source code?
I've had a number of people inquire about a Mac/Linux version of my Coyote-1 device management application (www.openstomp.com) and without a Mac/Linux version of the Propeller Tool available that didn't seem like a very useful thing to work on. I tried out the latest build of your tool on a Mac and it successfully compiled my device's code base (though I haven't yet tested the image it generated, or compared it to the Propeller tool's binary), so it seems like a Mac/Linux option may actually be worth pursuing.
Again, Great work. Very impressive!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
Yes, it was developed completely from scratch.
In every instance I've tested so far, yes.. My test suite is over 1600 spin files including everything in the Object exchange, Hydra forum and Hydra CD. Thus far, every generated binary is bit for bit identical to the output of the Parallax compiler. I do have one corner case I know about with chaining round(float( type of things that will give a 1lsb error, but I'm working on it.
Ta. If the binary it generates is not identical then I'd love a copy of the spin source so I can fix it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Have you got the 32 bit gtk libraries installed?
Try "ldd ./bst" and see if there are any missing dependencies. Here is my output
brad@bklaptop2:~$ ldd `which bst` linux-gate.so.1 => (0xb805a000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7f5c000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7f44000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7bcc000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7b48000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7b0c000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7a5b000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7a56000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7a52000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7a14000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb79fc000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb79e2000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb79de000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb788f000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb788c000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7874000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb784f000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7846000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7843000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7840000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb783a000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb77d8000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb77ae000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb77a0000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7798000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7794000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb778c000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7786000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb777d000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7756000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb774c000) /lib/ld-linux.so.2 (0xb805b000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7749000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7744000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb771d000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb76b0000) libz.so.1 => /usr/lib/libz.so.1 (0xb769a000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7677000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb764e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb755b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7550000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb752e000)▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Firstly I' m real happy I can program native on Linux and Mac. The code I'm working on is just one file because is mostly assembler (except for the initial cognews), so the file has some 4700 lines. Either with or without syntax highlight the editor feels slow. I type some chars sort of fast and they lag to show; the cursor also moves slowly. This is in an AthlonXP (1.83 GHz), Ubuntu 7.04, with the corresponding blob for the graphics card. (I'm using BST 0.13). Can something be done ? (besides getting a faster computer ?)
thanks,
ALe
Yes, I did something dumb when I built the editor and only realised last week what I did, so it's fixed in the next release (which should be out sometime after saturday)
Sorry about that, but yes the editors performance sucks in those early versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
before you release the next version, here is a little bug I just found:
If I write this:
long (k4_b<<26)+@m_B_cfg_curr+16
or this :
long (k4_b<<26)+16+@m_B_cfg_curr
I get the error message "Expected Spin Instruction, Unique Name, Floating point Constant, etc
long @m_B_cfg_curr+(k4_b<<26)+16
It does not error.
Thanks!
Excellent catch! That would only exhibit itself if the first component of an expression was a parentheses block *and* there was a @ in the expression. Apparently none of my test suite has those conditions [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Check the top post for changelog as usual, but read on to get more detail on the additional features (of which there are a few).
You can now click on the grey line marking the code-block and the entire block will collapse.
There is now an option for find/replace to search the whole file scope. Find will just loop around when it hits the end, as will replace, whereas replace-all will move the cursor to the top of the file and go from there.
We now have an option to assign individual propeller ports to editor tabs, so I can select a tab and download the right code to the right propeller if I have multiple props connected (ide prefs checkbox). Right-Click->Assign Propeller from inside the editor.
After careful consideration, I decided that being able to assign a port to an editor tab is pretty naff unless we have the ability to make it persistent, so I introduce you to "The Project File". A concept shamelessly ripped of from numerous IDE's from time immemorial (Well, actually Delphi 1 was my first encounter)
The project file is entirely optional, you don't need one and it won't impact you in any way should you choose to shun this option. Having said that, you can create one at any time from your current editor configuration by simply asking to save a project file.
The project file saves :
- What tabs you have open
- What order the tabs are
- Where each editor tab is scrolled to
- What propeller port is assigned to that tab
- What code folds you have active in that tab
If you close the project file, it will close all the tabs you currently have open. Let me re-state that. CLOSE PROJECT, CLOSE ALL TABS!
Now if you close the editor, it will prompt you to save all the current tabs contents, then it will ask you to save the project. You don't have to do this, you can tell it to not save just the same as you can decline to save an editor file.
There is an option in the ide preferences that will, when enabled, re-open the project you had open when you last closed the ide. If you saved everything as you were closing, then you will find your workspace re-opened precisely as you left it.
The project menu has a recent projects menu, just like recent files, and you can use this to jump between projects in completely different locations. When you open a new project, the current project is entirely closed (as are all its tabs) and the new one opened.
There is now an option to save the recovery file on a timed basis in addition to the auto-recover-save prior to each compile. Settable in minutes between 2 and 120 (see the ide prefs for details) Remember, the auto-recover-save is not saving your edited files to disk, merely saving a representation of any unsaved files in the editor in case it should crash. bst is the only thing that can read these files back again (and it should do in the event of it being re-started after a crash)
From the "standing on the shoulders of giants" department (read as this is built from Lazarus and FreePascal) we have the line changed indicators (same as delphi, visual studio and numerous other GUIs). It's a new addition to the Lazarus stable and therefore it cost me very little to build in, so there it is (it's also optional).
Pruning some more "low hanging fruit", I've managed to speed up the tokeniser in the compiler again to give an overall speed increase of 30% on the last release. This has also translated into a faster highlighter and more responsive editor (especially on my 400Mhz G4!). An updated and accelerated command line compiler will be forthcoming.
The project support is really new and it might well have usability "issues". Stuff like it asking you to save unsaved tabs twice on close and things like that. You report 'em and I'll fix 'em [noparse]:)[/noparse]
I think I've squashed every bug reported so far, but if I've missed yours please yell loudly.
As always, feedback warmly welcomed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I've started loosing connection to the propeller during upload on a more frequent basis in the last couple releases.
but here is the interesting one I've found...
A few programmers like to use ' and { together. However bst won't see the '} and assume that the brackets are
not being used.
Example: (from HDMF, but Baggers likes to do this too. [noparse]:)[/noparse] )
str+=9 repeat t from 0 to 7 nibble := i & $0000000f if nibble =< 9 BYTE[noparse][[/noparse]str] := 48 {'0'} + nibble else BYTE[noparse][[/noparse]str] := CONSTANT(65 {'A'} - 10) + nibble str-- i >>= 4At the {'0'} things start to go haywire, and everything beyond is remarked.
Thanks again for a great program! BST has become my "standard" tool now.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Oh yes, I can see why that occurs. I'll get it fixed. Thanks [noparse]:)[/noparse]
I'll also investigate the comms. I've been making some subtle changes to the serial code to try and make Windows behave better and I'm sure that I've not been paying enough attention to the timing effects on Linux and MacOS. Will look into it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
One thing I have been experiencing on all pre 14 versions is that quite often the "+" block fold icons ten to lose their place, the sometimes don't fold themselves, and very frequently become erratic. Folding all blocks will reset the issue though, so it is a good work around. (XP)
On the OSX version which I don't use much (yet), I notice that the default highlighter color is very hard to see as the blue is very similar to the highlight color. XP is fine to distinguish the two, but I think the OSX version could use some contrasting measure.
Thanks again.
All those issues should be fixed in the latest version. There was a serious amount of work went into various ugly bugs in the block folder.
I'd be _really_ interested to hear of any reproducible nasties in it now.
No worries. I'm thinking about configurable keystrokes and configurable highlighter colours/parameters in the next version or two, so hopefully we can iron out some of the OS specific colour issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
A couple of bugs so far:
1) The attached file does strange things on the last fold, maybe because it has a commented out PUB routine inside a con section.
2) I have had some trouble with the projects. Once I get it working it works great, but creating a project file the first time has given me trouble. I am still a bit confused about what is happening, more when I understand it more, but you my want to take a look at the save dialog box. Sometimes it defaults to "name-of-the-last-tab-saved.spin", instead of 'something.sprj'
The folds are working much better, many times a day prior to 14, the mouse wheel would stop allowing any scrolling past a certain point, fold all would resolve it for a short time but it always came back. No problems now after a few hours on XP.
Oooo thanks. I've had a few cases lately of bst compiling invalid code. I'll nail that one.
Glad the folding is working better [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
The problem there is we have 2 folds beginning on the same line.
con <- is the first level, then {{ <- is the second. The block folder only folds the first available level on the block stack when you click the [noparse][[/noparse]x].
I have to think about how to go about fixing this one. I'm still debating the utility of having {} and {{}} be their own foldable blocks. If I removed that then the problem would go away. I'd rather fix it to properly fold the nested blocks though.
Yes, I can see how that happens. I don't change the default filename of the save box when setting it up to save a project file. I'll make sure that is fixed.
I've found one or two other little niggles with the project handling I need to think about also. Easy workaround for that problem is to type in a full filename with the .sprj on the end when saving a project for the first time.
Cheers for the feedback.
One note for linux users if you have more than one ftdi device connected. I've found if you have 2 or more devices on a USB2 hub they can interfere with one another and cause large timeout delays in the linux driver. I work around this by having one on the hub and one connected directly to a root port on the PC. Just something to watch anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I can confirm this. I thought it was a problem with VMWare but it may have not been. I had a Intronix LogicPort connected to a hub that has the Ale's PropClip. Using the two of them together caused loss of connection from BST to the Propeller. (Linux).
The projects is something I also asked you-know-who
Yeah, the project file thing fell out of the need to be able to save which port was allocated to which tab. I do have plans to enhance it further but it looks like I'm going to be moving countries again shortly so I might be confined to bug fixes for a while.
Did the latest revision solve your cursor speed/lag issue? I can't fix the scroll speed or re-paint speed. It's an artifact of the way the font gets painted begin slow under gtk2 (I can't use the normal painting methods as the character width is doing strange things with the Parallax font). I did find a major bug where I was re-painting the entire window each time the cursor moved. That was slowing things down a _lot_.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I was reading about all of the things that are saved in a "Project", and I wonder if you could save object paths in projects as well. I might have one project using a new revision of an object, while another might still use an old revision.
As a Linux user, I have to say you hit the nail on the head with BST. The Propeller was one of the few remaining reasons to keep Windows on my computer. One more gone!
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
I have been thinking about having a project specific override for both compiler paths and compiler options (optimisations). I need to think some more about how I might get that to work with the current configuration system. Thanks for the prompt, it's now on the todo list.
Thanks for the kind words, I'm glad you find it usable (notwithstanding the bugs).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I second that. I'm using OS X and my experiece of programming the Propeller has improved tremendously since I stopped having to use Windows. Now I don't have to go through the extra step of making sure my Prop files on the virtual machine are getting backed up. And now it's so much easier to use Quartz Composer to visual the debug/telemetry data coming off the Prop.
Brad, thanks a lot. You may be wondering how many people use and appreciate your software. I use it every day. I know there's several linux users here, and probably a lot more OS X users than one might think.