It's a difficult one.
Windows has OK buttons on everything. (A bit like Fisher Price builds a teething ring into every toy)
Mac has OK buttons on nothing.
Linux has Ok buttons some places and not in others.
Personally I try to only put OK buttons where there is a corresponding cancel button. In this case you add or remove a path, there is no ok or cancel operation to perform.
I aiming for a reasonably intuitive and minimalist interface. In this place, I'm not sure an ok button really has a function.
Maybe one that have text "Done"
It is not all folks that thinking in same way and is more reliable that only close buton in high upper corner
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I used a program called ScreenShot on the Ubuntu system, so I do not know what is in the attachement. Hopefully you can see the letters that are running together, and the 'n' looking like an 'r'. Again, Ubuntu 8.10 64 bit, the screen is 1280x800. The suggestion that was in the Wiki did not make a difference that I could tell. Hope this helps, once the bugs are gone then maybe I will have more confidence in the program, otherwise, BST looks pretty good.
Rsadeika said...
I used a program called ScreenShot on the Ubuntu system, so I do not know what is in the attachement. Hopefully you can see the letters that are running together, and the 'n' looking like an 'r'. Again, Ubuntu 8.10 64 bit, the screen is 1280x800. The suggestion that was in the Wiki did not make a difference that I could tell. Hope this helps, once the bugs are gone then maybe I will have more confidence in the program, otherwise, BST looks pretty good.
Mm that is a font mismatch. That is not the propeller font and not monospaced. I'll have to knock up an install of Ubuntu 8.10 on 64 bit and see if I can reproduce it.
Can you possibly do me a screenshot of the IDE preferences box with the font selection box open and Parallax 12 selected? I would like to see how it renders in the gtk selection box.
I just downloaded the new version and something really odd happens with it and the current debug. From clean unzip when I run it it seg faults, but if I use gdb first on it once, then I can run it normally after. Also, I do get gtk warnings, but I imagine I can clean those up by upgrading my version of gtk. The warning is about no property "gtk-cursor-blink-timeout" on line 9876.
I just downloaded the new version and something really odd happens with it and the current debug. From clean unzip when I run it it seg faults, but if I use gdb first on it once, then I can run it normally after. Also, I do get gtk warnings, but I imagine I can clean those up by upgrading my version of gtk. The warning is about no property "gtk-cursor-blink-timeout" on line 9876.
gtk warnings are just a fact of life. I get them here and I'm running precisely the version I compiled it for. Just ignore them.
Can you run me through the process from unzip step by step?
Do you mean after you've run it under gdb once then you can just run it normally until you upgrade or change the binary?
What about after a reboot?
I've not put up any new debug builds, so the one that is there is the one I put up for you last time around. If you want one I'll do a debug build of the latest code.
Can you run me through the process from unzip step by step?
Do you mean after you've run it under gdb once then you can just run it normally until you upgrade or change the binary?
What about after a reboot?
I've not put up any new debug builds, so the one that is there is the one I put up for you last time around. If you want one I'll do a debug build of the latest code.
Ah, the first time I ran the debug version was with gdb...
Today, I saw the new version and downloaded it then:
#get rid of the old
rm bst
rm bst.linux
#unzip
unzip bst.linux
#try to run
./bst.linux #this segfaults
# try to revert to the debug version that I know worked before removing it
unzip bst-debug.zip
./bst # seg fault
#Well, this will have debug info brad can use let's see what gdb says...
gdb ./bst #works...
#odd... Let's try it again without debug.
./bst # magically works...
# Hey, wonder if that works on the new build...
gdb ./bst.linux #this works
#close the application
#try again without debugger
./bst.linux #this magically works now
So, if I run it through the debugger once after unzipping, it works... It doesn't make sense to me why this would be, but for some reason it is.
#try again without debugger
./bst.linux #this magically works now
[noparse][[/noparse]/code]
So, if I run it through the debugger once after unzipping, it works... It doesn't make sense to me why this would be, but for some reason it is.
Ok, so that has me completely scratching my bonce. I'll put together a debug build for you with full symbols and internal backtrace mechanism.
Hopefully the first time you unzip it and run it, it will crash and give us a backtrace we can work with.
Needless to say, don't run it in gdb when you unzip it [noparse];)[/noparse]
Brad. I have not tested programming ram/eeprom on a MAC yet, but on the pc, the main window seems to lose focus on every F10/F11, and I have to click on the window to be able to program again.
Example:
F10: programs fine
F10: nothing happens
Click app window
F10: programs fine
This is not really an issue for most, as you would rarely click F10 or F11 twice, which would be redundant, however in cases where I use F10 to restart the operating system numerous times for test purposes rather than power Off/On, it becomes more an issue. I really don't care if you fix it, but wanted you to be aware that it is losing focus somehow on F10/11. I suspect your pseudo popup for program progress is causing the main window to give up focus.
Thanks again for writing this app, it is a very welcome and appreciated tool. I have a program with over 2000 lines that I will be tweaking for years to come on a regular basis, so the retractable blocks are a great addition.
Can you run me through the process from unzip step by step?
Do you mean after you've run it under gdb once then you can just run it normally until you upgrade or change the binary?
What about after a reboot?
I've not put up any new debug builds, so the one that is there is the one I put up for you last time around. If you want one I'll do a debug build of the latest code.
Ah, the first time I ran the debug version was with gdb...
Today, I saw the new version and downloaded it then:
#get rid of the old
rm bst
rm bst.linux
#unzip
unzip bst.linux
#try to run
./bst.linux #this segfaults
# try to revert to the debug version that I know worked before removing it
unzip bst-debug.zip
./bst # seg fault
#Well, this will have debug info brad can use let's see what gdb says...
gdb ./bst #works...
#odd... Let's try it again without debug.
./bst # magically works...
# Hey, wonder if that works on the new build...
gdb ./bst.linux #this works
#close the application
#try again without debugger
./bst.linux #this magically works now
So, if I run it through the debugger once after unzipping, it works... It doesn't make sense to me why this would be, but for some reason it is.
Ok, I have finally nailed this.
It's a bug in UnionFS on the Eee (it affects a number of applications). When you create a new executable on the filesystem, the kernel can't find the link /proc/self/exe (which causes bad things to happen the program I'm afraid).
The workaround (as un-linuxy as it sounds) is to reboot the eee after unzipping the file.
Whatever gdb is doing, it's waking the kernel up to the fact there is a new file on the system and once that happens it will run just fine. Rebooting has precisely the same affect but more predictable.
I've got an Eee 701 running in a VM here and I can reproduce your symptoms precisely, but if I unzip the file and reboot it works first time, every time.
Nasty, but according to all sources a bug present in the Eee 701 and 901.
Originator said...
Brad. I have not tested programming ram/eeprom on a MAC yet, but on the pc, the main window seems to lose focus on every F10/F11, and I have to click on the window to be able to program again.
Example:
F10: programs fine
F10: nothing happens
Click app window
F10: programs fine
This is not really an issue for most, as you would rarely click F10 or F11 twice, which would be redundant, however in cases where I use F10 to restart the operating system numerous times for test purposes rather than power Off/On, it becomes more an issue. I really don't care if you fix it, but wanted you to be aware that it is losing focus somehow on F10/11. I suspect your pseudo popup for program progress is causing the main window to give up focus.
Your suspicion is very close. I was chasing a peculiar bug a while back and I deliberately de-focussed the main window while the compiler window was open. I've fixed this and it will be in the next revision. Thanks for the pointer.
So, if I run it through the debugger once after unzipping, it works... It doesn't make sense to me why this would be, but for some reason it is.
Ok, I have finally nailed this.
It's a bug in UnionFS on the Eee (it affects a number of applications). When you create a new executable on the filesystem, the kernel can't find the link /proc/self/exe (which causes bad things to happen the program I'm afraid).
The workaround (as un-linuxy as it sounds) is to reboot the eee after unzipping the file.
Whatever gdb is doing, it's waking the kernel up to the fact there is a new file on the system and once that happens it will run just fine. Rebooting has precisely the same affect but more predictable.
I've got an Eee 701 running in a VM here and I can reproduce your symptoms precisely, but if I unzip the file and reboot it works first time, every time.
Nasty, but according to all sources a bug present in the Eee 701 and 901.
I think gdb and g++ are from build-essentials on the Eee PC repos. I noticed I don't have to reboot when adding packages through apt, or compiling locally, I'd guess that they have a built in work around. I suppose using gdb to not have to reboot should be enough.
Post Edited (J. A. Streich) : 11/9/2008 3:52:21 AM GMT
O Ive got a suggestion, that I dont think I've seen yet. Maybe its a bug, but not that big a deal to really be a bug.
Can the file list on the bottom left, jump to what every char is entered on the keyboard, I hate scrolling looking for them all the time.
if this is a PITA, dont worry about it.
TJHJ said...
O Ive got a suggestion, that I dont think I've seen yet. Maybe its a bug, but not that big a deal to really be a bug.
Can the file list on the bottom left, jump to what every char is entered on the keyboard, I hate scrolling looking for them all the time.
if this is a PITA, dont worry about it.
I can do it if you click in there first to focus it. Is that an acceptable limitation?
If you attempt to load a file that doesn't exist, it crashes :
Brads SpinTool Loader v0.03 - Copyright 2008, All rights reserved
Compiled for i386 Linux at 12:45:45 on 2008/10/21
Could not load Binary
An unhandled exception occurred at $0804C940 :
EAccessViolation : Access violation
$0804C940
$080481BF
I have yet to try your tools, but i just though of a feature for you that would be very handy for pasm optimizations: Preprocessor commands for automatic loop unrolling (not sure if anyone already suggested this)
something like:
<code A>
UNROLL_START 3
<code B>
UNROLL_END
<code C>
would result in the following right before compilation
<code A>
<code B>
<code B>
<code B>
<code C>
Sure you'd agree the former is much more maintainable than the latter one
One can also introduce macro like CUR_ITER, which will be substituted with a literal corresponding to the current iteration of unrolling.
If you attempt to load a file that doesn't exist, it crashes :
Nice find. I fixed this in bst but forgot to fix it in bst[noparse][[/noparse]lc]. I've been meaning to get a new release out (the compiler has more speedups), so I'll do that in the next day or so.
Cheers [noparse]:)[/noparse]
I just downloaded the OS X version. The serial terminal cuts off the last few characters of every line. The same thing happens in the compile info window.
Thanks a lot for writing this, I really didn't like having to boot up VMWare just to program the Propeller. I imagine there is probably too much incompatibility in the code, but do you have any plans to make a Cocoa version? I'd pay good money for a Cocoa IDE.
Jay Kickliter said...
I just downloaded the OS X version. The serial terminal cuts off the last few characters of every line. The same thing happens in the compile info window.
Can you get me a screenshot of that? If I can see it and I can reproduce it I'll fix it.
<edit> What happens if you resize the window? </edit>
Jay Kickliter said...
Thanks a lot for writing this, I really didn't like having to boot up VMWare just to program the Propeller. I imagine there is probably too much incompatibility in the code, but do you have any plans to make a Cocoa version? I'd pay good money for a Cocoa IDE.
Yeah, sorry. Not in the immediate future. The tools I'm using make the widgetsets quite similar across the platforms and allow me to have minimal {$IFDEF}s in my code. Carbon is a procedural interface and is relatively similar to existing widgetsets. Cocoa is a completely different kettle of fish and quite a ways off. Just looking at trying to write something cross-platform with Cocoa makes me go cross eyed.
In any case, the 32Bit Carbon interface I'm using is fully native to OSX. What particular advantage do you see to a Cocoa based interface?
The reason why I asked about Cocoa, it that it just plain looks nicer. I can almost always tell a Carbon app by looking at it. I think it may have something to do with the text anti-aliasing, but I'm not sure. Its not a big deal, and I appreciate the work you've done. I don't know what your plan is once you get this out of beta, but I'll certainly contribute some money if you make this shareware.
Jay Kickliter said...
Brad, I've attached a screen shot.
The reason why I asked about Cocoa, it that it just plain looks nicer. I can almost always tell a Carbon app by looking at it. I think it may have something to do with the text anti-aliasing, but I'm not sure. Its not a big deal, and I appreciate the work you've done. I don't know what your plan is once you get this out of beta, but I'll certainly contribute some money if you make this shareware.
Excellent. That looks like Monaco from here but I can't be really sure, can I trouble you to have a look in the font dialog and let me know what Font and size that actually is so I can test it locally? Also, what particular version of OSX are you using? (I've got stacks of different versions archived away here, plus a couple of different architecture Macs, so it makes testing a bit easier) Nevermind, at Monaco 14 point I've reproduced it precisely. I'll have it fixed in the next release. Workaround is to select another font size. In the serial terminal you can do that with cmd-shift-up/dn or in the File->Font dialog box. Unfortunately in the list window you can't do that. I'll make sure that is rectified in the next release also.
Unfortunately, the text anti-aliasing has been and will likely continue to be a bit of an issue. I'm working on "Macifying" the Parallax font so it displays better at fractional sizes, but it's incredibly low down on my list of things to do [noparse]:)[/noparse] I will however attend to any rendering problems that crop up (like you appear to have found) and try my best to swat all the bugs people find as I work on the program.
Once it's out of beta (will it ever be out of beta?) my plan is pretty much to continue the same way I've done thus far. I have zero intention of charging for or limiting the software in any way.
I actually use this pretty heavily myself, so it's important to me that it does what I need it to do. The fact other people can make use of it also is a pretty big bonus and it certainly gives me some incentive to add bits I don't normally use myself.
Everyone else in this forum gives so much, it's nice to be able to give back a little.. know what I mean ?
A minor niggle. If I run bst with insufficient privileges to access the port (or no port at all I guess) then I cannot compile anything, F8 gives me a scary message about data corruption and a stack trace jumps out of the terminal (I guess that's the compiler giving up). Same for compile and save binary/eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A minor niggle. If I run bst with insufficient privileges to access the port (or no port at all I guess) then I cannot compile anything, F8 gives me a scary message about data corruption and a stack trace jumps out of the terminal (I guess that's the compiler giving up). Same for compile and save binary/eeprom.
That's really strange. I can compile no problems on machines that have no ports at all.
What OS and version are you using? Reproduced here. I'll get it fixed for the next release. Thanks! You guys are so much better at testing the more obscure stuff than I am [noparse]:)[/noparse]
I was not catching a particular exception when you have insufficient permission on a port. It's quite safe to tell the program to continue. It won't corrupt anything.
BradC said...
Thanks! You guys are so much better at testing the more obscure stuff than I am [noparse]:)[/noparse]
I think a lot of us here have been busy trying to break things since we learned how to wield our first plastic hammers.
Some times we can even put them back together again [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BradC said...
Thanks! You guys are so much better at testing the more obscure stuff than I am [noparse]:)[/noparse]
I think a lot of us here have been busy trying to break things since we learned how to wield our first plastic hammers.
Some times we can even put them back together again [noparse]:)[/noparse]
It's funny you say that. I tell people I spent the first 15 years of my life pulling stuff to bits. It then took me an additional 5 years to learn to put it all back together again.
I still have this little baggie of bits left over. My philosophy is if there are parts left over and it still works, it was over-engineered to begin with [noparse]:)[/noparse]
Ha ! That great. I always had parts left over as well and came to the same conclusion. I've noticed that doctors quite often have that idea to [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
It's a difficult one.
Windows has OK buttons on everything. (A bit like Fisher Price builds a teething ring into every toy)
Mac has OK buttons on nothing.
Linux has Ok buttons some places and not in others.
Personally I try to only put OK buttons where there is a corresponding cancel button. In this case you add or remove a path, there is no ok or cancel operation to perform.
I aiming for a reasonably intuitive and minimalist interface. In this place, I'm not sure an ok button really has a function.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Maybe one that have text "Done"
It is not all folks that thinking in same way and is more reliable that only close buton in high upper corner
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Mm that is a font mismatch. That is not the propeller font and not monospaced. I'll have to knock up an install of Ubuntu 8.10 on 64 bit and see if I can reproduce it.
Can you possibly do me a screenshot of the IDE preferences box with the font selection box open and Parallax 12 selected? I would like to see how it renders in the gtk selection box.
I'll see if I can get a 64bit VM installed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I just downloaded the new version and something really odd happens with it and the current debug. From clean unzip when I run it it seg faults, but if I use gdb first on it once, then I can run it normally after. Also, I do get gtk warnings, but I imagine I can clean those up by upgrading my version of gtk. The warning is about no property "gtk-cursor-blink-timeout" on line 9876.
gtk warnings are just a fact of life. I get them here and I'm running precisely the version I compiled it for. Just ignore them.
Can you run me through the process from unzip step by step?
Do you mean after you've run it under gdb once then you can just run it normally until you upgrade or change the binary?
What about after a reboot?
I've not put up any new debug builds, so the one that is there is the one I put up for you last time around. If you want one I'll do a debug build of the latest code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Ah, the first time I ran the debug version was with gdb...
Today, I saw the new version and downloaded it then:
So, if I run it through the debugger once after unzipping, it works... It doesn't make sense to me why this would be, but for some reason it is.
Have you got the Parallax font installed?
Can you give me some more information to go on? What font have you got selected?
This screenshot is what it _should_ look like if you have the Parallax font installed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Ok, so that has me completely scratching my bonce. I'll put together a debug build for you with full symbols and internal backtrace mechanism.
Hopefully the first time you unzip it and run it, it will crash and give us a backtrace we can work with.
Needless to say, don't run it in gdb when you unzip it [noparse];)[/noparse]
I'll PM you the link when it's uploaded.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Example:
F10: programs fine
F10: nothing happens
Click app window
F10: programs fine
This is not really an issue for most, as you would rarely click F10 or F11 twice, which would be redundant, however in cases where I use F10 to restart the operating system numerous times for test purposes rather than power Off/On, it becomes more an issue. I really don't care if you fix it, but wanted you to be aware that it is losing focus somehow on F10/11. I suspect your pseudo popup for program progress is causing the main window to give up focus.
Thanks again for writing this app, it is a very welcome and appreciated tool. I have a program with over 2000 lines that I will be tweaking for years to come on a regular basis, so the retractable blocks are a great addition.
Ok, I have finally nailed this.
It's a bug in UnionFS on the Eee (it affects a number of applications). When you create a new executable on the filesystem, the kernel can't find the link /proc/self/exe (which causes bad things to happen the program I'm afraid).
The workaround (as un-linuxy as it sounds) is to reboot the eee after unzipping the file.
Whatever gdb is doing, it's waking the kernel up to the fact there is a new file on the system and once that happens it will run just fine. Rebooting has precisely the same affect but more predictable.
I've got an Eee 701 running in a VM here and I can reproduce your symptoms precisely, but if I unzip the file and reboot it works first time, every time.
Nasty, but according to all sources a bug present in the Eee 701 and 901.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Your suspicion is very close. I was chasing a peculiar bug a while back and I deliberately de-focussed the main window while the compiler window was open. I've fixed this and it will be in the next revision. Thanks for the pointer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (J. A. Streich) : 11/9/2008 3:52:21 AM GMT
Can the file list on the bottom left, jump to what every char is entered on the keyboard, I hate scrolling looking for them all the time.
if this is a PITA, dont worry about it.
Awesome work as always,
Thanks again,
TJ
Macbook Pro 2.4 core 2 , OSx 10.5.5
I can do it if you click in there first to focus it. Is that an acceptable limitation?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
A non-critical bug in bstl -
If you attempt to load a file that doesn't exist, it crashes :
Brads SpinTool Loader v0.03 - Copyright 2008, All rights reserved
Compiled for i386 Linux at 12:45:45 on 2008/10/21
Could not load Binary
An unhandled exception occurred at $0804C940 :
EAccessViolation : Access violation
$0804C940
$080481BF
-adrian
I have yet to try your tools, but i just though of a feature for you that would be very handy for pasm optimizations: Preprocessor commands for automatic loop unrolling (not sure if anyone already suggested this)
something like:
<code A>
UNROLL_START 3
<code B>
UNROLL_END
<code C>
would result in the following right before compilation
<code A>
<code B>
<code B>
<code B>
<code C>
Sure you'd agree the former is much more maintainable than the latter one
One can also introduce macro like CUR_ITER, which will be substituted with a literal corresponding to the current iteration of unrolling.
Cheers
Nice find. I fixed this in bst but forgot to fix it in bst[noparse][[/noparse]lc]. I've been meaning to get a new release out (the compiler has more speedups), so I'll do that in the next day or so.
Cheers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Thanks a lot for writing this, I really didn't like having to boot up VMWare just to program the Propeller. I imagine there is probably too much incompatibility in the code, but do you have any plans to make a Cocoa version? I'd pay good money for a Cocoa IDE.
Can you get me a screenshot of that? If I can see it and I can reproduce it I'll fix it.
<edit> What happens if you resize the window? </edit>
Yeah, sorry. Not in the immediate future. The tools I'm using make the widgetsets quite similar across the platforms and allow me to have minimal {$IFDEF}s in my code. Carbon is a procedural interface and is relatively similar to existing widgetsets. Cocoa is a completely different kettle of fish and quite a ways off. Just looking at trying to write something cross-platform with Cocoa makes me go cross eyed.
In any case, the 32Bit Carbon interface I'm using is fully native to OSX. What particular advantage do you see to a Cocoa based interface?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
The reason why I asked about Cocoa, it that it just plain looks nicer. I can almost always tell a Carbon app by looking at it. I think it may have something to do with the text anti-aliasing, but I'm not sure. Its not a big deal, and I appreciate the work you've done. I don't know what your plan is once you get this out of beta, but I'll certainly contribute some money if you make this shareware.
Excellent. That looks like Monaco from here but I can't be really sure, can I trouble you to have a look in the font dialog and let me know what Font and size that actually is so I can test it locally? Also, what particular version of OSX are you using? (I've got stacks of different versions archived away here, plus a couple of different architecture Macs, so it makes testing a bit easier) Nevermind, at Monaco 14 point I've reproduced it precisely. I'll have it fixed in the next release. Workaround is to select another font size. In the serial terminal you can do that with cmd-shift-up/dn or in the File->Font dialog box. Unfortunately in the list window you can't do that. I'll make sure that is rectified in the next release also.
Unfortunately, the text anti-aliasing has been and will likely continue to be a bit of an issue. I'm working on "Macifying" the Parallax font so it displays better at fractional sizes, but it's incredibly low down on my list of things to do [noparse]:)[/noparse] I will however attend to any rendering problems that crop up (like you appear to have found) and try my best to swat all the bugs people find as I work on the program.
Once it's out of beta (will it ever be out of beta?) my plan is pretty much to continue the same way I've done thus far. I have zero intention of charging for or limiting the software in any way.
I actually use this pretty heavily myself, so it's important to me that it does what I need it to do. The fact other people can make use of it also is a pretty big bonus and it certainly gives me some incentive to add bits I don't normally use myself.
Everyone else in this forum gives so much, it's nice to be able to give back a little.. know what I mean ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 11/9/2008 4:11:03 PM GMT
A minor niggle. If I run bst with insufficient privileges to access the port (or no port at all I guess) then I cannot compile anything, F8 gives me a scary message about data corruption and a stack trace jumps out of the terminal (I guess that's the compiler giving up). Same for compile and save binary/eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That's really strange. I can compile no problems on machines that have no ports at all.
What OS and version are you using? Reproduced here. I'll get it fixed for the next release. Thanks! You guys are so much better at testing the more obscure stuff than I am [noparse]:)[/noparse]
I was not catching a particular exception when you have insufficient permission on a port. It's quite safe to tell the program to continue. It won't corrupt anything.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 11/10/2008 4:25:13 AM GMT
Is is a simple thing to add Fold All Blocks?
Hrm, I _thought_ I added Fold All Blocks in the last release. (0.11)
Right click (or ctrl-click) menu in the editor.
In any case, it's much improved in 0.12 and baring any more odd bugs I should have that out this afternoon/evening.
You can only fold blocks if you have line numbering turned on (it requires the display of the gutter on the left hand side for folding)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
I think a lot of us here have been busy trying to break things since we learned how to wield our first plastic hammers.
Some times we can even put them back together again [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 11/10/2008 12:08:36 PM GMT
It's funny you say that. I tell people I spent the first 15 years of my life pulling stuff to bits. It then took me an additional 5 years to learn to put it all back together again.
I still have this little baggie of bits left over. My philosophy is if there are parts left over and it still works, it was over-engineered to begin with [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.