Oh, and on my Mac mini, not sure if it's something I need to fix, but F8-F11 etc don't work, they bring up the audio settings, anyone know how to fix that?
Baggers, you can change that from System Preferences, I think from Keyboard (or Keyboard/Mouse, depending on which OS you're running).
Cheers, MG117
Brad, on BST(c) there is an error that says "please report this bug"
"Bytecode of object exceeds size of memory"
This occurs after adding some code(spin). Prior to adding the code that gives the error, the compile says
Prog 7088 longs
Var 288
Stack/free 812
I have been having this happen lately. I have had programs compile that were much larger than this, and small code being added should not be pushing it over the limit. Remove unused, safe opti are both on. Without these it would have stopped compiling a long time ago due to size.
The problems seems to exist for adding different code, not just one specific instruction that I can track down.
Even with the "remove unused code" option enabled, the first pass compile always compiles in _all_ code. It has to do that so it can start the process of figuring out what is not used. I'll wager that your object size exceeds 32k with all code enabled.
I'll have to have a think about how I get around that I suppose.
I've just got back after 4 weeks away, so I need some time to get organised and try and squash the issues people have reported lately and I'll try and figure out the best way to sort the issue for you.
I've been meaning to try and remove the object size limits in the compiler anyway as I'll have to do it for bigspin and I guess the Prop II eventually. At the moment all the object code is based around a hard 32k object size limit.
A couple bugs. I've searched back several pages and didn't see these mentioned.
Every time a folder is selected that contains enough files to warrant a scroll bar, none appears and the scroll wheel does not work. As soon as the window is resized it works as expected.
Also, the red "x" in the upper right does not close anything when several files are open.
After a bit of a hiatus from programming I've started to dip a toe back into the water. I've posted 0.19.4-pre13 which has some basic BASIC highlighting and a few bug fixes.
I've not had a chance to scroll back and look at all the bug reports I've missed over the last few months, but I promise to do so.
I've had some pretty major overhauls of the tool chain recently(ish) and I've not even had time to get my PPC Mac out of mothballs, so other than a quick boot test on Linux this snapshot is literally the current state of my development tree before I quietly went insane and hid under a desk for 6 months or so. It's likely to be chock full or surprises.
I don't promise to be as responsive as I have been in the past, but hopefully over the next couple of months I can work my way back to full capacity and get back on the horse.
Baggers, you can change that from System Preferences, I think from Keyboard (or Keyboard/Mouse, depending on which OS you're running).
Cheers, MG117
Just spotted this thanks MacGeek117, works now, although I had to change the Fkeys to F16-F19 instead of F8-F11, as they seem to be fixed on Audio play/pause etc.
Brad,
Just a couple things I noticed with 19.4 Pre13
The editor window doesn't go to the bottom of the screen. I can force it down by turning on "View->Errors", but if I turn off "View->Errors" it goes back up again.
The cursor is not visable when it is all the way to the left. Makes it hard to see what line you are on when move down through code.
The file tabs are gone from the top of the editor. No way to move between files.
This is running on Windows 7 Home Premium 64-bit if that makes a difference.
Hrm. It would appear that the updates I did to my toolchain have broken the widget alignment and auto-sizing on all three widget sets. Spectacular Fail!
What is this, a touch of burn out?. Nothing too serious I hope. Some how that statement rings a bell for me.
More literal than metaphorical.
Burn out is there too I guess. I've worked solidly on bst from Oct 2008 until June 2010, and I guess I've just had to scale it back a couple of notches. Plus, you have to admit the business model is not so compelling.
I've got a project coming up I want to use the Prop for, but a lot of my stuff has gone back to single chip solutions. When you don't need the horsepower of the counters or cogs, dropping a single $1 18 pin chip on a board is pretty compelling.
Hopefully this fixes the issues with missing bits in the last snapshot and it *should* (read that as it does here) fix the issue with the scroll bar in OSX 10.6. Please let me know if it doesn't and I'll have another crack at it.
Any chance of getting an updated bstc which fixes the negative offset issue (when using -Or)? It's not urgent, basically just checking if it's still on your list ...
Any chance of getting an updated bstc which fixes the negative offset issue (when using -Or)? It's not urgent, basically just checking if it's still on your list ...
Absolutely. I recall fixing that a while back in the source tree. Can I ask you to try the latest bst snapshot just to confirm it works for your particular case? If it's ok then I'll build up and post a revised bstc tonight.
Absolutely. I recall fixing that a while back in the source tree. Can I ask you to try the latest bst snapshot just to confirm it works for your particular case? If it's ok then I'll build up and post a revised bstc tonight.
The latest IDE you posted uses bstc-0.15.4-pre11 (or so it tells me) but still falls over [post=910581]this particular issue[/post].
The latest IDE you posted uses bstc-0.15.4-pre11 (or so it tells me) but still falls over [post=910581]this particular issue[/post].
Ooooohkay then. The latest bst uses the latest compiler code (revision number notwithstanding) so I still have an issue. I'll have a look at it tonight and see what jumps out at me.
I've recently rearranged my desk. I'm using an iMac with dual monitors. I used to have the second monitor on the right side but after the rearrangement it is now on the left. When running BST I would have it displayed on the second monitor. Today when I started up BST the splash screen would appear and then nothing. I opened up a new file but it was nowhere to be found. I downloaded BST again and reinstalled, still nothing would appear. After trying some other things I decided to see if changing the display configuration would have any effect. Yep, there was BST still displayed on the right side even when there was no display configured over there. So I dragged it to the main screen, reconfigured the displays, and then dragged it over to the left screen.
I've recently rearranged my desk. I'm using an iMac with dual monitors. I used to have the second monitor on the right side but after the rearrangement it is now on the left. When running BST I would have it displayed on the second monitor. Today when I started up BST the splash screen would appear and then nothing. I opened up a new file but it was nowhere to be found. I downloaded BST again and reinstalled, still nothing would appear. After trying some other things I decided to see if changing the display configuration would have any effect. Yep, there was BST still displayed on the right side even when there was no display configured over there. So I dragged it to the main screen, reconfigured the displays, and then dragged it over to the left screen.
Rich H
Yep. Mike Green alerted me to this one a while back and it's the next bug on my squash list. I've only just managed to get a dual head setup running (apple cheaped out on the original intel mini's and shared the DDC port between digital and analogue so it won't work under OSX). In fact the first time I booted bst under OSX to test it a couple of days ago I copped precisely the same issue. The nasty fix is to delete the geometry line in ~/Library/Preferences/bst.ini, but a proper fix is forthcoming.
My PPC box has a dual head card in it so when I can get OSX running dual head I'll be able to find out what part of the screen geometry I'm not properly checking for.
BradC: Have you looked at the ZipIt thread lately? How difficult would it be to compile bst for the ARM under linux? Do you have the time? ZipIt2 is now $10 in the US
BradC: Have you looked at the ZipIt thread lately? How difficult would it be to compile bst for the ARM under linux? Do you have the time? ZipIt2 is now $10 in the US
I started working on the arm toolchain some months ago.
Has anyone identified a GPIO pin you can access and flip to reset the prop?
bst is probably a stretch. GTK2 is pretty memory hungry and bst uses quite a bit of it. I might be able to look at a qt port though.
bstc / bstl is probably a lot more realistic, and it's something I can look at after Christmas if someone can give me a verified GPIO so I can modify mine for testing.
<edit> *or* you could install Mono on the zippit and use homespun right now. Team that with a self-compiled version of RossH's payload for ARM modified to use a GPIO for reset (you can do it, you have the source).
I started working on the arm toolchain some months ago.
Wow, excellent.
bst is probably a stretch. GTK2 is pretty memory hungry and bst uses quite a bit of it. I might be able to look at a qt port though.
Don't even think running BST on the Zipit, the screen is tiny and it would be terrible slow anyway. BSTC fine.
However for the 1GHz ARM boards like the IGEP and Beagle BST will be great.
As for Qt:
I think you will find it is as huge as anything else or even bigger.
The killer is all Qt graphics relies on floating point, there is no floating point hardware on a Zipit ARM. Just for fun I built one of our Qt apps from work for the ARM and tried it on the Zipit. Well, it's glacially slow. Like a factor 100 or so.
Again that's no problem for Beagle or IGEP that have newer ARMS with FP hardware.
I thought about mono and HomeSpun. I don't think mono on ARM has a JIT compiler so that may be slow as well. But perhaps speed is not so important for a command line compiler.
Thank you for this great tool. I have known about the propeller for years now, but the fact that i had to use windows in order to use it was holding me back. I happened to find your tool a few days ago and ordered a propeller chip immediately, which i am happily using now.
These is one thing bothering me with bst: the source editor lags when scrolling fast through the source. It appears like just a small portion of it is buffered as it works fine when scrolling slowly. Is there some parameter you can change for the object with the text view to increase the buffer size and hence make i scroll smoothly? It would be really nice
These is one thing bothering me with bst: the source editor lags when scrolling fast through the source. It appears like just a small portion of it is buffered as it works fine when scrolling slowly. Is there some parameter you can change for the object with the text view to increase the buffer size and hence make i scroll smoothly? It would be really nice
To quote No 5. "Need more input".
On my test systems it lags on a 400Mhz Mac PPC, but is just fine on a quad core i7. What operating system and processor are you seeing the issue on?
To try and emulate the highlighter on the Propeller tool, the highlighter is quite complex (probably moreso than it needs to be) and is very processor intensive particularly when scrolling.
On my test systems it lags on a 400Mhz Mac PPC, but is just fine on a quad core i7. What operating system and processor are you seeing the issue on?
To try and emulate the highlighter on the Propeller tool, the highlighter is quite complex (probably moreso than it needs to be) and is very processor intensive particularly when scrolling.
I have tried on my laptop running 64-bit ubuntu 10.04, 2.53ghz core2duo and on my desktop with 3.0 ghz core2duo and 32-bit ubuntu 10.10. It works better on my desktop, but it is not perfect. Eclipse, for instance, scrolls really well even on my laptop and there is a LOT going on in the eclipse source editor.
This is not really a big problem, but i was hoping there was a simple solution.
In Linux kernel after 2.6.30, CP210x driver has been changed to wait for DCD line become active before open() call returns. So, when using bst with CP2102, bst hangs forever. Brad, would you mind changing the software to pass O_NDELAY to open() call (and handle EAGAIN properly)?
Is anyone else having a problem with bst producing empty archives or have I stumbled onto a new bug?
I am running bst 0.19.3 on an 86_64 Intel Core 2 Duo CPU with Mandriva 2009 Linux kernal 2.6.27-desktop-0.rc8.2mnb installed.
I first load and compile the spin files and then click file:create archive. The zip then appears in the directory with the spins. Upon opening I find all the files but they are all empty.
Comments
Cheers, MG117
Even with the "remove unused code" option enabled, the first pass compile always compiles in _all_ code. It has to do that so it can start the process of figuring out what is not used. I'll wager that your object size exceeds 32k with all code enabled.
I'll have to have a think about how I get around that I suppose.
I've just got back after 4 weeks away, so I need some time to get organised and try and squash the issues people have reported lately and I'll try and figure out the best way to sort the issue for you.
I've been meaning to try and remove the object size limits in the compiler anyway as I'll have to do it for bigspin and I guess the Prop II eventually. At the moment all the object code is based around a hard 32k object size limit.
A couple bugs. I've searched back several pages and didn't see these mentioned.
Every time a folder is selected that contains enough files to warrant a scroll bar, none appears and the scroll wheel does not work. As soon as the window is resized it works as expected.
Also, the red "x" in the upper right does not close anything when several files are open.
OS X 10.6.4
Rich H
After a bit of a hiatus from programming I've started to dip a toe back into the water. I've posted 0.19.4-pre13 which has some basic BASIC highlighting and a few bug fixes.
I've not had a chance to scroll back and look at all the bug reports I've missed over the last few months, but I promise to do so.
I've had some pretty major overhauls of the tool chain recently(ish) and I've not even had time to get my PPC Mac out of mothballs, so other than a quick boot test on Linux this snapshot is literally the current state of my development tree before I quietly went insane and hid under a desk for 6 months or so. It's likely to be chock full or surprises.
I don't promise to be as responsive as I have been in the past, but hopefully over the next couple of months I can work my way back to full capacity and get back on the horse.
What is this, a touch of burn out?. Nothing too serious I hope. Some how that statement rings a bell for me.
Just spotted this thanks MacGeek117, works now, although I had to change the Fkeys to F16-F19 instead of F8-F11, as they seem to be fixed on Audio play/pause etc.
Just a couple things I noticed with 19.4 Pre13
The editor window doesn't go to the bottom of the screen. I can force it down by turning on "View->Errors", but if I turn off "View->Errors" it goes back up again.
The cursor is not visable when it is all the way to the left. Makes it hard to see what line you are on when move down through code.
The file tabs are gone from the top of the editor. No way to move between files.
This is running on Windows 7 Home Premium 64-bit if that makes a difference.
Thanks for all your hard work...
Bean
This might take me a while to sort out.
More literal than metaphorical.
Burn out is there too I guess. I've worked solidly on bst from Oct 2008 until June 2010, and I guess I've just had to scale it back a couple of notches. Plus, you have to admit the business model is not so compelling.
I've got a project coming up I want to use the Prop for, but a lot of my stuff has gone back to single chip solutions. When you don't need the horsepower of the counters or cogs, dropping a single $1 18 pin chip on a board is pretty compelling.
Hopefully this fixes the issues with missing bits in the last snapshot and it *should* (read that as it does here) fix the issue with the scroll bar in OSX 10.6. Please let me know if it doesn't and I'll have another crack at it.
Absolutely. I recall fixing that a while back in the source tree. Can I ask you to try the latest bst snapshot just to confirm it works for your particular case? If it's ok then I'll build up and post a revised bstc tonight.
The latest IDE you posted uses bstc-0.15.4-pre11 (or so it tells me) but still falls over [post=910581]this particular issue[/post].
Ooooohkay then. The latest bst uses the latest compiler code (revision number notwithstanding) so I still have an issue. I'll have a look at it tonight and see what jumps out at me.
I've recently rearranged my desk. I'm using an iMac with dual monitors. I used to have the second monitor on the right side but after the rearrangement it is now on the left. When running BST I would have it displayed on the second monitor. Today when I started up BST the splash screen would appear and then nothing. I opened up a new file but it was nowhere to be found. I downloaded BST again and reinstalled, still nothing would appear. After trying some other things I decided to see if changing the display configuration would have any effect. Yep, there was BST still displayed on the right side even when there was no display configured over there. So I dragged it to the main screen, reconfigured the displays, and then dragged it over to the left screen.
Rich H
Yep. Mike Green alerted me to this one a while back and it's the next bug on my squash list. I've only just managed to get a dual head setup running (apple cheaped out on the original intel mini's and shared the DDC port between digital and analogue so it won't work under OSX). In fact the first time I booted bst under OSX to test it a couple of days ago I copped precisely the same issue. The nasty fix is to delete the geometry line in ~/Library/Preferences/bst.ini, but a proper fix is forthcoming.
My PPC box has a dual head card in it so when I can get OSX running dual head I'll be able to find out what part of the screen geometry I'm not properly checking for.
I started working on the arm toolchain some months ago.
Has anyone identified a GPIO pin you can access and flip to reset the prop?
bst is probably a stretch. GTK2 is pretty memory hungry and bst uses quite a bit of it. I might be able to look at a qt port though.
bstc / bstl is probably a lot more realistic, and it's something I can look at after Christmas if someone can give me a verified GPIO so I can modify mine for testing.
<edit> *or* you could install Mono on the zippit and use homespun right now. Team that with a self-compiled version of RossH's payload for ARM modified to use a GPIO for reset (you can do it, you have the source).
Wow, excellent.
Don't even think running BST on the Zipit, the screen is tiny and it would be terrible slow anyway. BSTC fine.
However for the 1GHz ARM boards like the IGEP and Beagle BST will be great.
As for Qt:
I think you will find it is as huge as anything else or even bigger.
The killer is all Qt graphics relies on floating point, there is no floating point hardware on a Zipit ARM. Just for fun I built one of our Qt apps from work for the ARM and tried it on the Zipit. Well, it's glacially slow. Like a factor 100 or so.
Again that's no problem for Beagle or IGEP that have newer ARMS with FP hardware.
I thought about mono and HomeSpun. I don't think mono on ARM has a JIT compiler so that may be slow as well. But perhaps speed is not so important for a command line compiler.
As for speed, well we just have to remember the days of the 8088 and 80286 and the 4 hours+ compiles to be satisfied
These is one thing bothering me with bst: the source editor lags when scrolling fast through the source. It appears like just a small portion of it is buffered as it works fine when scrolling slowly. Is there some parameter you can change for the object with the text view to increase the buffer size and hence make i scroll smoothly? It would be really nice
Thank you
To quote No 5. "Need more input".
On my test systems it lags on a 400Mhz Mac PPC, but is just fine on a quad core i7. What operating system and processor are you seeing the issue on?
To try and emulate the highlighter on the Propeller tool, the highlighter is quite complex (probably moreso than it needs to be) and is very processor intensive particularly when scrolling.
I have tried on my laptop running 64-bit ubuntu 10.04, 2.53ghz core2duo and on my desktop with 3.0 ghz core2duo and 32-bit ubuntu 10.10. It works better on my desktop, but it is not perfect. Eclipse, for instance, scrolls really well even on my laptop and there is a LOT going on in the eclipse source editor.
This is not really a big problem, but i was hoping there was a simple solution.
Once again, thank you for bst.
I am running bst 0.19.3 on an 86_64 Intel Core 2 Duo CPU with Mandriva 2009 Linux kernal 2.6.27-desktop-0.rc8.2mnb installed.
I first load and compile the spin files and then click file:create archive. The zip then appears in the directory with the spins. Upon opening I find all the files but they are all empty.
bst reports an error, while bstc crashes:
Linux debian 2.6.32-5-686
Let me know when you are working on BST. I have updated the PropBasic compiler and I'll send you the latest files.
Bean