Here reporting from Mac OS 10.6.2 Intel (I'll try 10.6.8 on the other machine). The preferencies menu works and with the shortcut too.
Top file key bindings, at least on my keyboard (an Apple Alu keyboard) you need to press the fn key together with the F8 (for instance) and CMD. On the Macbook too. In a Normal PC keyboard you get the function key without the fn key... I really got burned in Prop Tool so many times due to compiling only the current file instead of the top file... Maybe you could add a shift to them.
I had a pig of a time getting that menu to work properly (or at all in fact) on 10.4. There are some significant Carbon bugs that got ironed out on 10.5, but they can cause huge backward compatibility issues in 10.4. Except for opening an associated file when bst is not running, everything should behave the same on 10.4/5/6. File associations are somewhat b0rked on 10.4 when bst is closed and I just can not seem to get it to work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Haven't been able to figure out how to print the pbas program being worked on while in the BST IDE.· I'm using the Windows version with XP.· I've been leaving the IDE and loading the pbas program into Windows Wordpad just to print then close Wordpad and go back to the BST IDE.· Is there an easier way?·
Eagleman said...
Haven't been able to figure out how to print the pbas program being worked on while in the BST IDE. I'm using the Windows version with XP. I've been leaving the IDE and loading the pbas program into Windows Wordpad just to print then close Wordpad and go back to the BST IDE. Is there an easier way?
Not currently no.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Did you ever have the compiler goto the first line causing an error?
As in, does the editor highlight the first error automatically ? No it doesn't. Should it?
The PropTool does, but of course only the first. You have a list of errors, but it does not go to the first one. I couldn't recall if you ever did this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Did you ever have the compiler goto the first line causing an error?
As in, does the editor highlight the first error automatically ? No it doesn't. Should it?
The PropTool does, but of course only the first. You have a list of errors, but it does not go to the first one. I couldn't recall if you ever did this.
If it ever did it was by accident more than design.
The Parallax compiler stops dead at the first error it encounters. bstc tries very hard to continue in case there are other errors it can point you at while its going about its business.
I guess its not hard to make it do that, but all the tools I use simply give you a nice list of errors/warnings/info and you just click on the one you want to look at. That is how I designed it as it's how I'm used to working. I'll look into it when I next have my head in that part of the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Since indentation is a big deal with Spin, are you considering adding a feature that would show this in BST? I sort of like the way Prop IDE handles it, gives a visual as what lines of code are included when you use a command like 'repeat', for instance.
Many years ago when I was a Parallax newbie, I asked for Linux support (and a lot of other things). I must say that Parallax has found away to deliver on nearly everything in spades.
About two years ago, I shifted over to Ubuntu Linux as Windows Vista failed to make my life easier in Taiwan due to its lack of support. I pretty much have retained Windows on dual boot with Ubuntu Linux just to be able to use Parallax's IDEs and am using Linux 98% of the time as it is more stable and far less annoying.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
Rsadeika said...
Since indentation is a big deal with Spin, are you considering adding a feature that would show this in BST? I sort of like the way Prop IDE handles it, gives a visual as what lines of code are included when you use a command like 'repeat', for instance.
Yeah, I have considered it and it is on my list of things to do. Unfortunately, it is not high on that list.
Next time I have my head in the highlighter I'll have another look at it. The biggest issue I found was how to render the little indicators without making horrific, hard to maintain changes to the highlighter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Best thing is to redesign Spin so that it has braces enclosing blocks. Then you won't need the "show me my indentation because I can't follow what I'm doing any more" cludge.
Sorry, just stirring [noparse]:)[/noparse]
The only way I can stop myself getting my indentation wrong is to keep my Spin methods really short so that it does not get too visually confusing. This is probably good programming practice anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Loopy Byteloose said...
Howdy,
I must say thanks for developing this.
No worries. I kinda wrote it to scratch my own itches. It's a bonus that other people take the time to find and report the bugs in it [noparse];)[/noparse]
Loopy Byteloose said...
Many years ago when I was a Parallax newbie, I asked for Linux support (and a lot of other things). I must say that Parallax has found away to deliver on nearly everything in spades.
About two years ago, I shifted over to Ubuntu Linux as Windows Vista failed to make my life easier in Taiwan due to its lack of support. I pretty much have retained Windows on dual boot with Ubuntu Linux just to be able to use Parallax's IDEs and am using Linux 98% of the time as it is more stable and far less annoying.
I have a windows XP VM I have to fire up from time to time, but life has been a lot better since that became an infrequent occurrence rather than daily.
Fortunately my windows contact these days is limited to testing and debugging win32 bst stuff, I don't actually "use" it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Cluso99 said...
Thanks Brad. I didn't realise I could click on the error and it would go to the error line. That's really neat
Also, if it can't find the file with the error/warning/info message in the open tabs, it'll open it up for you.
@Heater, noooooooooooooooo! Just use a larger tab space and the indentation becomes blindingly obvious. I generally find a tab of 4 is a good compromise.
I guess a few years of editing python in vim and gedit before I discovered the Propeller helped with the indentation stuff. I never even used the indent markers on the prop tool while I was still using that. I thought they just cluttered the screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I made a passing comment about how much I liked your support of #ifdefs in BST in response to a comment by Mike Green. Let me include it here because
I had a question for you and it is unreasonable of me to expect you to see every passing BST comment unless it is in this thread.
JackBak said...
Yeah, I like BST as well. I started using it on my linux system but needed PASD so I went back to my XP box. Now I just tried BST on the XP and everything is good
(I love Brad's inclusion of ifdefs) but I can't seem to debug with PASD unless I am using the Parallax IDE. So no more BST and ifdefs .... sigh.
Note to Brad if he sees this: Can we code fold based on defines ala emacs? or even manually if you put the +- box by the ifdefs
That was in the "Using an array" thread, and I know that the PASD thing is in Ariba's camp. I was more concerned with the code folding idea.
I made a passing comment about how much I liked your support of #ifdefs in BST in response to a comment by Mike Green. Let me include it here because
I had a question for you and it is unreasonable of me to expect you to see every passing BST comment unless it is in this thread.
JackBak said...
Yeah, I like BST as well. I started using it on my linux system but needed PASD so I went back to my XP box. Now I just tried BST on the XP and everything is good
(I love Brad's inclusion of ifdefs) but I can't seem to debug with PASD unless I am using the Parallax IDE. So no more BST and ifdefs .... sigh.
Note to Brad if he sees this: Can we code fold based on defines ala emacs? or even manually if you put the +- box by the ifdefs
I'm not sure how emacs works, I've never had enough hard disk space to install it [noparse];)[/noparse]. Vim here.
In theory it's possible. In practice it's a little more difficult. At the moment the block folder is a single level construct. You can't nest methods or blocks, so I never implemented a block stack. #if/blah can be nested and therefore requires a block stack.
The other question is, what do you fold? The entire #ifdef / #endif block or each #ifdef #elseifdef #else component individually?
It has also been suggested that I parse the #define's so that the text in non-active defines is greyed out like a comment. The problem with doing that is you need to know the context of which parent object the defines may be passed down from. It gets extremely ugly very quickly.
I had planned to get back inside the highlighter in the not to distant future to do some work for PropBASIC highlighting, so it's something I can certainly look at.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC said...
It has also been suggested that I parse the #define's so that the text in non-active defines is greyed out like a comment. The problem with doing that is you need to know the context of which parent object the defines may be passed down from. It gets extremely ugly very quickly.
Yes, I can see it getting ugly as you suggest.
BradC said...
The other question is, what do you fold? The entire #ifdef / #endif block or each #ifdef #elseifdef #else component individually?
How about keeping it simple put the +- block around the #ifdef #elseifdef #else elements and the user can fold or not manually.
And forget I said anything about emacs I would rather stay away from religion
This has some *major* changes to the way serial ports are configured internally and some detection changes for Windows users. Could people please bang on this a bit (particularly windows users who swap between different props and serial ports) to see if it is more reliable in detecting your propellers?
Linux and Mac users should see no changes, but the majority of the code is common, so if you would not mind beating it up a bit I'd appreciate it.
Bean pointed out it was not detecting > COM99 on Windows. It should now reliably see any hardware serial ports on a system. It may miss Bluetooth, IR and virtual ports though, and as I don't have any I can't test that.
The Com port config is a bit complex. I'll try to explain how it works.
bst has three locations it looks for a valid port.
The first is the project file. If you have a propeller assigned to a specific tab in your project file (right click -> Assign Propeller in the editor) it will try and use that port for your prop. If it can't find a prop there you can either ignore it (NO), manually search/select (YES) or do an automated search (ALL). Either of the two search options will update the port assignment for the tab. This *always* has precedence over any other port assignments. You can clear this assignment by using (right click -> Assign Propeller) and selecting "Auto".
The second is the IDE Config (Tools -> IDE Preferences -> IDE Preferences -> Configure Ports). Any port selected in here will be applied to all tabs by default (unless as above they have a port manually set). You can set this to a manually selected port, or auto selection as above.
The third is the last known propeller that was not manually assigned to a tab. This gets updated any time we find a propeller. and if there is no per-tab or global selection, we try this port first every time there is no manual selection either globally or for the tab.
Complex to explain, but hopefully relatively easy to use. Most users should be able to just find the first prop using F7 and go from there.
Windows users will probably need to do a search (F7->All) when they change propellers / ports, but after that it should just work.
You can't assign individual ports per tab in projects until you have "Tools->IDE Preferences->IDE Preferences->Allow an individual port per edit tab" checked. If this is unchecked then global port preferences apply to all tabs. You only want this selected if you are doing multi-prop projects and want to be able to assign different propellers to different tabs.
Other minor changes :
All -Properly remember terminal settings on all platforms (Brian Riley)
All -Remember the last port we had open in the terminal (Cluso99)
All -Only bring terminal to front if prop loaded successfully (Cluso99)
All -Suppress SPIN warning/info for PropBASIC compiles (Bean)
This is -pre-pre-pre release as the internal plumbing changes are *huge* and the testing they've received is very limited.
Feedback gratefully accepted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I just did a quick test of the port detection, I am running the Windows 0.19.2-Pre1 BST version. The original problem is still there, but what saves the day is the "All" choice, that seems to find, and associate the correct port. So, when I do the propeller switch, it gets hung up on not finding the correct port, but, again the "All" seems to take care of the problem. Just wanted to give you some quick feedback on that aspect.
Brad,
I have another request...
Could you support faster baud rates in the terminal program ? I'm currently using 230400 but may even use faster than that.
Hyperterminal supports past 460800 baud.
Just an idea. No biggie.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Possible bug: Strange behaviour with #defines that exist in the code and in the project defines dialog.
I have "SOMETHING" and "TriBladeProp" as defines in the Project defines dialog box.
I have the following code:
PUB start
#define SOMETHING
#define TriBladeProp
This gives me the correct error: "Error - SOMETHING - Already Defined."
However when I comment out or remove "#define SOMETHING" I do not get any error on the redefinition of TriBladeProp.
I've played with this a bit. Even cutting and pasting the name strings form code to dialog and vice versa to be sure they are the same. Can't find a rule that triggers this behaviour.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Possible bug: Strange behaviour with #defines that exist in the code and in the project defines dialog.
Wow.. I can. There is a bug in the compiler, and a bug in bst. Thankfully the compiler bug does not stop them from behaving as they should. The bug in bst prevents proper duplicate checking unless the defines in the project box are all uppercase. (It's a case sensitivity issue). Nice catch! It'll be fixed in 0.19.2-pre2, which given I've had nobody scream about me breaking (or fixing for that matter) propeller detection serial port issues, I guess is probably just about ready to go.
@Bean, sure I can look at other baud rates. bst already uses 230,400 to download to the prop if you have "fast download" selected in the compiler options, so it can't be too hard to add it to the terminal. I'll have to verify that rates faster than that work properly on all three platforms though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I don't know if anyone already mentioned this: The listing output doesn't correctly expand tab characters (9). Instead of taking the current output offset into account, it seems to always emit 8 spaces. I know, it's just cosmetics, but should be relatively easy to fix!?
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Brad The Mac version is awesome! any way to add the logical block-groups highlight? as a new guy that feature helps in learning to write code and catching coding mistakes witch saves lots of time . let me know what you can do. i would love to work on my 8 core, not my p4
pullmoll said...
I don't know if anyone already mentioned this: The listing output doesn't correctly expand tab characters (9). Instead of taking the current output offset into account, it seems to always emit 8 spaces. I know, it's just cosmetics, but should be relatively easy to fix!?
The listing emits the source as processed by the compiler, and the tab expansion into 8 spaces is how the Parallax Compiler appears to do it so bstc does it that way too.
Probably easy enough to fix in the compiler, but then it's possible to break compatibility in some very odd corner case. Don't really want to do that.
@wb7076, the block group stuff has been asked for a lot lately. It's on the todo list, but it's not high up I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Ok, no feedback on the serial detection / configuration so I assume its good to go. Here is 0.19.2
Changelog up top as usual.
Biggies :
- Will now properly detect > COM99 on Windows.
- Won't jam up on Vista-> when hitting F10 twice in quick succession.
- Should behave if PropBASIC generates code the Spin compiler would normally warn about
- Mac / Linux users should remember terminal settings across sessions (windows already did this)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
When Compiling ZiCog by hitting F8 in the top object, zicog_cpm_lmm.spin, all goes well.
Accidentally hitting F8 in the lower object, zicog.spin, results in the crash.
In previous BST versions compilation would fail doing that, with unresolved symbols due to some code being hidden behind #defines that are defined in the top object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
When Compiling ZiCog by hitting F8 in the top object, zicog_cpm_lmm.spin, all goes well.
Accidentally hitting F8 in the lower object, zicog.spin, results in the crash.
In previous BST versions compilation would fail doing that, with unresolved symbols due to some code being hidden behind #defines that are defined in the top object.
I'm in front of the development box now, if you can attach a copy of the source that causes it to crash I'll get it fixed immediately.
<edit> Nevermind, I found it in the zicog thread and can reproduce it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Comments
Here reporting from Mac OS 10.6.2 Intel (I'll try 10.6.8 on the other machine). The preferencies menu works and with the shortcut too.
Top file key bindings, at least on my keyboard (an Apple Alu keyboard) you need to press the fn key together with the F8 (for instance) and CMD. On the Macbook too. In a Normal PC keyboard you get the function key without the fn key... I really got burned in Prop Tool so many times due to compiling only the current file instead of the top file... Maybe you could add a shift to them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
I had a pig of a time getting that menu to work properly (or at all in fact) on 10.4. There are some significant Carbon bugs that got ironed out on 10.5, but they can cause huge backward compatibility issues in 10.4. Except for opening an associated file when bst is not running, everything should behave the same on 10.4/5/6. File associations are somewhat b0rked on 10.4 when bst is closed and I just can not seem to get it to work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Not currently no.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Did you ever have the compiler goto the first line causing an error?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
That's very odd. It's only supposed to do that if it successfully loads the prop. I'll get it fixed.
As in, does the editor highlight the first error automatically ? No it doesn't. Should it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
If it ever did it was by accident more than design.
The Parallax compiler stops dead at the first error it encounters. bstc tries very hard to continue in case there are other errors it can point you at while its going about its business.
I guess its not hard to make it do that, but all the tools I use simply give you a nice list of errors/warnings/info and you just click on the one you want to look at. That is how I designed it as it's how I'm used to working. I'll look into it when I next have my head in that part of the code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Ray
I must say thanks for developing this.
Many years ago when I was a Parallax newbie, I asked for Linux support (and a lot of other things). I must say that Parallax has found away to deliver on nearly everything in spades.
About two years ago, I shifted over to Ubuntu Linux as Windows Vista failed to make my life easier in Taiwan due to its lack of support. I pretty much have retained Windows on dual boot with Ubuntu Linux just to be able to use Parallax's IDEs and am using Linux 98% of the time as it is more stable and far less annoying.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Ain't gadetry a wonderful thing?
aka G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan
Yeah, I have considered it and it is on my list of things to do. Unfortunately, it is not high on that list.
Next time I have my head in the highlighter I'll have another look at it. The biggest issue I found was how to render the little indicators without making horrific, hard to maintain changes to the highlighter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Sorry, just stirring [noparse]:)[/noparse]
The only way I can stop myself getting my indentation wrong is to keep my Spin methods really short so that it does not get too visually confusing. This is probably good programming practice anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
No worries. I kinda wrote it to scratch my own itches. It's a bonus that other people take the time to find and report the bugs in it [noparse];)[/noparse]
I have a windows XP VM I have to fire up from time to time, but life has been a lot better since that became an infrequent occurrence rather than daily.
Fortunately my windows contact these days is limited to testing and debugging win32 bst stuff, I don't actually "use" it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Also, if it can't find the file with the error/warning/info message in the open tabs, it'll open it up for you.
@Heater, noooooooooooooooo! Just use a larger tab space and the indentation becomes blindingly obvious. I generally find a tab of 4 is a good compromise.
I guess a few years of editing python in vim and gedit before I discovered the Propeller helped with the indentation stuff. I never even used the indent markers on the prop tool while I was still using that. I thought they just cluttered the screen.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I made a passing comment about how much I liked your support of #ifdefs in BST in response to a comment by Mike Green. Let me include it here because
I had a question for you and it is unreasonable of me to expect you to see every passing BST comment unless it is in this thread.
That was in the "Using an array" thread, and I know that the PASD thing is in Ariba's camp. I was more concerned with the code folding idea.
Thanks,
Jack
I'm not sure how emacs works, I've never had enough hard disk space to install it [noparse];)[/noparse]. Vim here.
In theory it's possible. In practice it's a little more difficult. At the moment the block folder is a single level construct. You can't nest methods or blocks, so I never implemented a block stack. #if/blah can be nested and therefore requires a block stack.
The other question is, what do you fold? The entire #ifdef / #endif block or each #ifdef #elseifdef #else component individually?
It has also been suggested that I parse the #define's so that the text in non-active defines is greyed out like a comment. The problem with doing that is you need to know the context of which parent object the defines may be passed down from. It gets extremely ugly very quickly.
I had planned to get back inside the highlighter in the not to distant future to do some work for PropBASIC highlighting, so it's something I can certainly look at.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Yes, I can see it getting ugly as you suggest.
How about keeping it simple put the +- block around the #ifdef #elseifdef #else elements and the user can fold or not manually.
And forget I said anything about emacs I would rather stay away from religion
Thanks,
Jack
This has some *major* changes to the way serial ports are configured internally and some detection changes for Windows users. Could people please bang on this a bit (particularly windows users who swap between different props and serial ports) to see if it is more reliable in detecting your propellers?
Linux and Mac users should see no changes, but the majority of the code is common, so if you would not mind beating it up a bit I'd appreciate it.
Bean pointed out it was not detecting > COM99 on Windows. It should now reliably see any hardware serial ports on a system. It may miss Bluetooth, IR and virtual ports though, and as I don't have any I can't test that.
Binaries here www.fnarfbargle.com/bst/snapshots
The Com port config is a bit complex. I'll try to explain how it works.
bst has three locations it looks for a valid port.
The first is the project file. If you have a propeller assigned to a specific tab in your project file (right click -> Assign Propeller in the editor) it will try and use that port for your prop. If it can't find a prop there you can either ignore it (NO), manually search/select (YES) or do an automated search (ALL). Either of the two search options will update the port assignment for the tab. This *always* has precedence over any other port assignments. You can clear this assignment by using (right click -> Assign Propeller) and selecting "Auto".
The second is the IDE Config (Tools -> IDE Preferences -> IDE Preferences -> Configure Ports). Any port selected in here will be applied to all tabs by default (unless as above they have a port manually set). You can set this to a manually selected port, or auto selection as above.
The third is the last known propeller that was not manually assigned to a tab. This gets updated any time we find a propeller. and if there is no per-tab or global selection, we try this port first every time there is no manual selection either globally or for the tab.
Complex to explain, but hopefully relatively easy to use. Most users should be able to just find the first prop using F7 and go from there.
Windows users will probably need to do a search (F7->All) when they change propellers / ports, but after that it should just work.
You can't assign individual ports per tab in projects until you have "Tools->IDE Preferences->IDE Preferences->Allow an individual port per edit tab" checked. If this is unchecked then global port preferences apply to all tabs. You only want this selected if you are doing multi-prop projects and want to be able to assign different propellers to different tabs.
Other minor changes :
All -Properly remember terminal settings on all platforms (Brian Riley)
All -Remember the last port we had open in the terminal (Cluso99)
All -Only bring terminal to front if prop loaded successfully (Cluso99)
All -Suppress SPIN warning/info for PropBASIC compiles (Bean)
This is -pre-pre-pre release as the internal plumbing changes are *huge* and the testing they've received is very limited.
Feedback gratefully accepted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Ray
Post Edited (Rsadeika) : 3/5/2010 12:52:07 PM GMT
I have another request...
Could you support faster baud rates in the terminal program ? I'm currently using 230400 but may even use faster than that.
Hyperterminal supports past 460800 baud.
Just an idea. No biggie.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
·
I have "SOMETHING" and "TriBladeProp" as defines in the Project defines dialog box.
I have the following code:
This gives me the correct error: "Error - SOMETHING - Already Defined."
However when I comment out or remove "#define SOMETHING" I do not get any error on the redefinition of TriBladeProp.
I've played with this a bit. Even cutting and pasting the name strings form code to dialog and vice versa to be sure they are the same. Can't find a rule that triggers this behaviour.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wow.. I can. There is a bug in the compiler, and a bug in bst. Thankfully the compiler bug does not stop them from behaving as they should. The bug in bst prevents proper duplicate checking unless the defines in the project box are all uppercase. (It's a case sensitivity issue). Nice catch! It'll be fixed in 0.19.2-pre2, which given I've had nobody scream about me breaking (or fixing for that matter) propeller detection serial port issues, I guess is probably just about ready to go.
@Bean, sure I can look at other baud rates. bst already uses 230,400 to download to the prop if you have "fast download" selected in the compiler options, so it can't be too hard to add it to the terminal. I'll have to verify that rates faster than that work properly on all three platforms though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The listing emits the source as processed by the compiler, and the tab expansion into 8 spaces is how the Parallax Compiler appears to do it so bstc does it that way too.
Probably easy enough to fix in the compiler, but then it's possible to break compatibility in some very odd corner case. Don't really want to do that.
@wb7076, the block group stuff has been asked for a lot lately. It's on the todo list, but it's not high up I'm afraid.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Changelog up top as usual.
Biggies :
- Will now properly detect > COM99 on Windows.
- Won't jam up on Vista-> when hitting F10 twice in quick succession.
- Should behave if PropBASIC generates code the Spin compiler would normally warn about
- Mac / Linux users should remember terminal settings across sessions (windows already did this)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
"Compiler Crashed!"
When Compiling ZiCog by hitting F8 in the top object, zicog_cpm_lmm.spin, all goes well.
Accidentally hitting F8 in the lower object, zicog.spin, results in the crash.
In previous BST versions compilation would fail doing that, with unresolved symbols due to some code being hidden behind #defines that are defined in the top object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm in front of the development box now, if you can attach a copy of the source that causes it to crash I'll get it fixed immediately.
<edit> Nevermind, I found it in the zicog thread and can reproduce it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Post Edited (BradC) : 3/10/2010 5:46:50 AM GMT