I'm terribly sorry to disappoint you, but there is no 64 bit version.
The reason it's not in bst/Latest is it has not been tested heavily enough to be considered for official release. I've boot tested it on three architectures and I've run the compiler regression suite on one. I still have an outstanding bug on OSX I can't find before I build and test release versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Bard said...
I'm terribly sorry to disappoint you, but there is no 64 bit version.
[noparse];)[/noparse] I meant testing the 32 regular versoin under 64b env. Instead of what I'm doing now (Using it through VirtualBox on a non-64b OS)
I installed the IA32 GTK lib as you suggested and so far, everything seems to be working fine. so as you said, there should not be a need for a 64bits version yet.
When I will receive my Prop later this week, I will do more testing.
Brad, not sure if this was fixed already since bst 18.5.8 but when trying to paste a word into the find text pane in the Find popup, there is a case where the find popup loses focus but shouldn't:
1. Go to any word in the program, highlight it
2. Copy the word
3. Go to any other word and highlight it
4. Do Find, find window pops up with currently highlighted word in it (great feature)
5. Try to Paste the old word that was copied from other location into the popup
Result:
Paste replaces the word in the main program that was subsequently highlighted. It should allow paste to occur in the find popup.
Not a big deal but just wanted to make sure it was known.
It looks like I broke unused spin method removal in this version (and it'll be broken in bstc too). If you get a "Relocation pointer error!!", just turn off spin method removal. I'll get it fixed asap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
More work on unused method removal. It now includes unused object removal.
The breakage was only apparent when you had an object included that was not actually used. The method table entries remained in the parent, but they were empty. When the linker went to hook it all up things went nasty.
Now, all traces of unused objects are removed. Bytecode, DAT blocks, entries in parent object method tables.. the whole box and dice. On the flip side, constants are accessible to your other objects, so you could include an object that only had a CON block with all your settings, and a dummy spin block and the object would have no size impact in the final code provided you did not reference any PUB objects in it.
<cries> Don't use unused object removal with this build either. It's broken still.. Everything else works, if that's any consolation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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'm almost scared to upload this, but it's out there. bst-0.19.4-pre11.
I've fixed the unused method / object removal properly this time.
Significant space savings are to be had with this option as it removes all traces of unused methods and entire unreferenced objects (it used to just exclude the method bytecode).
It cuts 78 longs out of the standard Propeller Demo supplied with the Demo board with no impact in functionality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Brad, small thing in bst-0.19.4-pre11 and earlier. When I am moving blocks of code
and the indentation is wrong in the official Prop IDE I could highlight the block and hit
the Tab key to re-indent the block. In bst it seems to delete the block of code.
JackBak said...
Brad, small thing in bst-0.19.4-pre11 and earlier. When I am moving blocks of code
and the indentation is wrong in the official Prop IDE I could highlight the block and hit
the Tab key to re-indent the block. In bst it seems to delete the block of code.
Just different key behaviour :
Ctrl-shift-I to block indent and Ctrl-shift-U to block un-indent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
JackBak said...
Ok, thanks Brad, duly noted, perhaps in the case I mention then the Tab key should quietly do nothing.
If you highlight some text in a text editor and press Tab, the text is replaced by a Tab. The behaviour of the Parallax tool, while convenient, is inconsistent with the behaviour of most other editing programs across all the supported platforms. I've already had Mac users poke me due to some HIG inconsistencies, I'm trying to progressively improve things [noparse]:)[/noparse]
If you do make an oops, ctrl-z is always there to put things back [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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...
Just different key behaviour :
Ctrl-shift-I to block indent and Ctrl-shift-U to block un-indent.
Can I recommend adding that to the Edit menu? I didn't know about that one. You may also want to bind Cmd-[noparse][[/noparse] and Cmd-] to indent and un-indent on the Mac. Xcode and BBEdit both use those and they have become second-nature over the years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
BradC said...
Just different key behaviour :
Ctrl-shift-I to block indent and Ctrl-shift-U to block un-indent.
Can I recommend adding that to the Edit menu? I didn't know about that one. You may also want to bind Cmd-[noparse][[/noparse] and Cmd-] to indent and un-indent on the Mac. Xcode and BBEdit both use those and they have become second-nature over the years.
Yes to both of those. No worries. I'm not actually sure what they are bound to currently in OSX, but I'll make it Cmd-[noparse][[/noparse]/] in the next snapshot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 was just wondering whether the possibility of sending control characters (Ctrl-X, Ctrl-V and Ctrl-T in my case) in Serial Terminal is still alive in your list of priorities in BST.
BST offers many desirable advantages ... especially having that automatic Serial port connection [noparse]:)[/noparse]
Your efforts are greatly appreciated.
Here is a small list of things I noticed while using the BST Windows version 0.19.3:
There is no way to specify the Top Spin file.
The serial terminal seems unable to use COM21 where one of my Propellers is connected.
Every so often, the loader can not find the propeller connected to COM8 (never a problem with PropTool).
The library path information does not seem to be saved/restored on BST restart (I put BST in c:\windows ... bad idea?).
Just one request if you have time:
Please provide a "pre-compile step" so that other tools may be invoked via script before normal Spin compile.
Thanks.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jazzed said...
* There is no way to specify the Top Spin file.
No. bst currently has no concept of "top file". It's something I'd like to rectify though.
jazzed said...
* The serial terminal seems unable to use COM21 where one of my Propellers is connected.
Is it not listed in the port selection menu or does it just not connect to it when you as it to?
jazzed said...
* Every so often, the loader can not find the propeller connected to COM8 (never a problem with PropTool).
An intermittent detection issue. Is it a prop-plug or ftdi converter? The last 3 pre-releases have had a *very* short reset pulse to try and help those using transistor RS232 converters. I might have made it a whisker short. How often does it do it?
jazzed said...
* The library path information does not seem to be saved/restored on BST restart (I put BST in c:\windows ... bad idea?).
No, should not matter where you put bst. On windows it stores its settings in the registry. (HKCU\Software\camsoft\bst\v0.1) or something like that.
Have a look at the "CompilerSearchPath" key and see what is there.
jazzed said...
Just one request if you have time:
Please provide a "pre-compile step" so that other tools may be invoked via script before normal Spin compile.
Awkward. What concerns me is people trying to use a pre-compile step to modify or pre-process source files prior to the compiler getting its grubby little hands on the source, because if the source is open in a tab the compiler sucks it straight from RAM and bypasses the disk entirely, so the behaviour may be confusing and inconsistent.
@dossic, yes. Sending Ctrl characters is planned. In the mean time, the latest pre-release snapshot allows you to send raw hex using the hex window, so you can send those characters directly. It's not as friendly, but it is possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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've not kept up on this thread, but do have an iMac. My question is how do you use tools such as PASD and ViewPort with this IDE? They NEED Windows.
I'm using Parallels and Windows XP to utilize the PropTool,and those tools to debug my programs. I'd be lost without them; PASD to debug initially the PASM cogs and ViewPort to verify the timing with the hardware the Props interface with.
I just realized there are some 50+ pages of responses to this thread. Thus I'd prefer not to start reading from the beginning of this thread.
Is there a summary of what this application does/does NOT provide?
jazzed said...
* Every so often, the loader can not find the propeller connected to COM8 (never a problem with PropTool).
An intermittent detection issue. Is it a prop-plug or ftdi converter? The last 3 pre-releases have had a *very* short reset pulse to try and help those using transistor RS232 converters. I might have made it a whisker short. How often does it do it?
My COM8 is a PropPlug. The frequency of failure is hard to quantify. I tried 10 times for each of the ports this morning without seeing any problems.
BradC said...
jazzed said...
Just one request if you have time:
Please provide a "pre-compile step" so that other tools may be invoked via script before normal Spin compile.
Awkward. What concerns me is people trying to use a pre-compile step to modify or pre-process source files prior to the compiler getting its grubby little hands on the source, because if the source is open in a tab the compiler sucks it straight from RAM and bypasses the disk entirely, so the behaviour may be confusing and inconsistent.
"What concerns me is people trying to use a pre-compile step to modify or pre-process source files"
Well, yes that's the point [noparse]:)[/noparse] In my case it's not changing a "text" source though, it is changing a "binary" that is included with the dat file "filename.bin" statement which is taken from the disk ... I guess someone could be silly enough to have that open in the editor though. I guess the McDonald's quality strategy analogy is necessary.
I'm fine with using BSTC in a script after compiling my binary with other tools, but the automatic serial port coordination goes away with that. Automatic serial port coordination is a major motivation for me to use BST on Windows.
The com21 and library path issues seem to have gone away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
"What concerns me is people trying to use a pre-compile step to modify or pre-process source files"
Well, yes that's the point [noparse]:)[/noparse] In my case it's not changing a "text" source though, it is changing a "binary" that is included with the dat file "filename.bin" statement which is taken from the disk ... I guess someone could be silly enough to have that open in the editor though. I guess the McDonald's quality strategy analogy is necessary.
I bet they never had this problem in the old days when you needed to understand how a machine worked to be able to use it! [noparse];)[/noparse] Abolish the web. Bring back gopher!
jazzed said...
I'm fine with using BSTC in a script after compiling my binary with other tools, but the automatic serial port coordination goes away with that. Automatic serial port coordination is a major motivation for me to use BST on Windows.
I'll admit the serial terminal is a neat feature. Especially so since Cluso99 made me re-focus the terminal after a good load. Best thing I've done all year.
I'll look into how I might achieve it cleanly. I'm already launching PropBASIC in a cross-platform manner, so it can't be *that* hard. It would likely be a project option only (Don't want someone setting a global up by mistake), but it'd then be managed in the project file. I can't promise it'll be a quick fix though. I'm pegged for a week or two. (gotta do real work to pay for bst development).
jazzed said...
The com21 and library path issues seem to have gone away.
Intermittent faults <grumble>
The -pre versions of bst have not been validated for release, and I've made significant blind timing changes to the loader recently (CRO is packed somewhere). I need to build a board that will let me plug an RS232 port in to test the issues with the transistor circuit on all my platforms before I run the loader validation tests. Intermittent failures would not surprise me right now as the reset pulse is *very* short (<2mS). I've just not had time to build the discrete RS232 interface to test with.
I'd actually like to be able to test with DTR / RTS resets in both polarities, but I need to get a bit clever and design a board for it I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Hey Brad,
just in case you're without anything to do, which I can't imagine, here's a suggestion regarding the warnings printed with -w2:
If a #-less jump's target is a ret instruction, the warning is superfluous, because you get what you expect. I don't know if your compiler has the opcode that is jumped to in reach to verify with 'ret', so it might be too complicated to suppress the warning in this specific case. Perhaps a compare for the target label ending with '_ret' is sufficient, though some very brain dead people might use xxx_ret for an address that has no ret instruction.
- Cmd-]/[noparse][[/noparse] block indent/outdent for Mac (I hope)
- Basic/Simple Syntax highlighting for PropBasic (Configure the text/background colour in the IDE Prefs menu)
- Pre-Compile binary execution for a project (in the project options box). Put the full file path/name and command line in the box. bst will complain loudly when you try to compile if you've got it wrong.
Now.. I really, really, really need feedback from Mac and Linux users on the next one.. pretty please with sugar on top.
When you right click on a tab in the tab bar at the top, the first item in the context menu should be the name of the tab you've right-clicked on. In previous versions it has always been the name of the currently showing tab. This should now properly work with any tab you click over.
The advantage of this is 2 new menu entries in that menu. "Move Tab Left" / "Move Tab Right". Provided the context menu shows the correct tab when you right-click on it, you can move your tabs around (slowly mind you).
This has the potential to go horribly wrong, and it was unreliable until very recently in the underlying tools (Lazarus LCL), which is why I had it locked to the currently open tab. I've tested this on Win32, Linux GTK2 & OSX 10.6.2 Intel.. I really need people with older versions of OSX to test it for me, and PPC users if possible. Open lots and lots of tabs (far more than will fill the screen) and scroll around the tabs right clicking on each one. If the name at the top of the menu is not the same as the tab you right clicked on then we still have a problem and I'll have to revert the behaviour.
<edit> this has been built and uploaded on my laptop as my ADSL is down, so I'm not sure entirely of the stability of this tool chain for Win32 & OSX.. be warned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
THANKS for highlighting possibility's to .pbas - BUT I have one dumb question on that.
Istead of have highlighting inbuilt in BST - What about lift them out to separate INI files highlighting.PASM, highlighting.SPIN, highlighting.PBAS, highlighting.C and so on.
That can give possibility's to USE BST even to edit other types of Files that are used with Programing PROPELLER.
On my XP moving TABS mostly function but not always In some cases I need first go to Tabs window and activated cursor in it before it will move TAB.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
THANKS for highlighting possibility's to .pbas - BUT I have one dumb question on that.
Istead of have highlighting inbuilt in BST - What about lift them out to separate INI files highlighting.PASM, highlighting.SPIN, highlighting.PBAS, highlighting.C and so on.
I can honestly say that getting the nuances required for good spin highlighting is beyond a simple .ini file and really requires a dedicated highlighter (the highlighter in bst is still getting some bits wrong). The highlighter has to be able to basically parse the source file so it knows which block it's in at any point. It's a bit complex, particularly with the block based folder.
The basic highlighter is quite a bit simpler right now. I could split that out into a separate file, but that then becomes a bit more complex than the "unzip and go" that I'm aiming for with bst.
Sapieha said...
That can give possibility's to USE BST even to edit other types of Files that are used with Programing PROPELLER.
Yes, but why would you want to? bst is written to compile spin and basic files in the simplest way possible. It can't currently talk to other third party compilers and it's missing a stack of features I'm sure you'd find in real editors.
Sapieha said...
On my XP moving TABS mostly function but not always In some cases I need first go to Tabs window and activated cursor in it before it will move TAB.
I have noticed one irregularity where if you are moving a tab that is not the active one things get odd. The tabs all wind up where you want them to, but odd tabs get selected and focussed at the same time.
Thanks for the feedback [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Brad,
Thanks for the PropBasic highlighting. Very cool.
I've noticed a couple keywords that don't get highlighted.
I assume you used the words in the RESERVED.TXT file ?
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Bean said...
Brad,
Thanks for the PropBasic highlighting. Very cool.
I've noticed a couple keywords that don't get highlighted.
I assume you used the words in the RESERVED.TXT file ?
Yes I did, but it's entirely possible I bolloxed bits of it up. I only put it together about an hour before I uploaded it, so It's sure to have broken bits. I just wanted to get it out there for testing and comment so I can refine it before the 0.19.4 release goes out.
As always, suggestions very welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm terribly sorry to disappoint you, but there is no 64 bit version.
The reason it's not in bst/Latest is it has not been tested heavily enough to be considered for official release. I've boot tested it on three architectures and I've run the compiler regression suite on one. I still have an outstanding bug on OSX I can't find before I build and test release versions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
[noparse];)[/noparse] I meant testing the 32 regular versoin under 64b env. Instead of what I'm doing now (Using it through VirtualBox on a non-64b OS)
I installed the IA32 GTK lib as you suggested and so far, everything seems to be working fine. so as you said, there should not be a need for a 64bits version yet.
When I will receive my Prop later this week, I will do more testing.
Thanks Over1 for the URL.
Thanks Brad for this application.
JM
1. Go to any word in the program, highlight it
2. Copy the word
3. Go to any other word and highlight it
4. Do Find, find window pops up with currently highlighted word in it (great feature)
5. Try to Paste the old word that was copied from other location into the popup
Result:
Paste replaces the word in the main program that was subsequently highlighted. It should allow paste to occur in the find popup.
Not a big deal but just wanted to make sure it was known.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
More work on unused method removal. It now includes unused object removal.
The breakage was only apparent when you had an object included that was not actually used. The method table entries remained in the parent, but they were empty. When the linker went to hook it all up things went nasty.
Now, all traces of unused objects are removed. Bytecode, DAT blocks, entries in parent object method tables.. the whole box and dice. On the flip side, constants are accessible to your other objects, so you could include an object that only had a CON block with all your settings, and a dummy spin block and the object would have no size impact in the final code provided you did not reference any PUB objects in it.
<cries> Don't use unused object removal with this build either. It's broken still.. Everything else works, if that's any consolation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 4/21/2010 9:21:32 AM GMT
I've fixed the unused method / object removal properly this time.
Significant space savings are to be had with this option as it removes all traces of unused methods and entire unreferenced objects (it used to just exclude the method bytecode).
It cuts 78 longs out of the standard Propeller Demo supplied with the Demo board with no impact in functionality.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
and the indentation is wrong in the official Prop IDE I could highlight the block and hit
the Tab key to re-indent the block. In bst it seems to delete the block of code.
As I say small thing just put it on the list.
Just different key behaviour :
Ctrl-shift-I to block indent and Ctrl-shift-U to block un-indent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
If you highlight some text in a text editor and press Tab, the text is replaced by a Tab. The behaviour of the Parallax tool, while convenient, is inconsistent with the behaviour of most other editing programs across all the supported platforms. I've already had Mac users poke me due to some HIG inconsistencies, I'm trying to progressively improve things [noparse]:)[/noparse]
If you do make an oops, ctrl-z is always there to put things back [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
Yes to both of those. No worries. I'm not actually sure what they are bound to currently in OSX, but I'll make it Cmd-[noparse][[/noparse]/] in the next snapshot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 was just wondering whether the possibility of sending control characters (Ctrl-X, Ctrl-V and Ctrl-T in my case) in Serial Terminal is still alive in your list of priorities in BST.
Thanks so much from Italy
Carlo
BST offers many desirable advantages ... especially having that automatic Serial port connection [noparse]:)[/noparse]
Your efforts are greatly appreciated.
Here is a small list of things I noticed while using the BST Windows version 0.19.3:
- There is no way to specify the Top Spin file.
- The serial terminal seems unable to use COM21 where one of my Propellers is connected.
- Every so often, the loader can not find the propeller connected to COM8 (never a problem with PropTool).
- The library path information does not seem to be saved/restored on BST restart (I put BST in c:\windows ... bad idea?).
Just one request if you have time:Please provide a "pre-compile step" so that other tools may be invoked via script before normal Spin compile.
Thanks.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
No. bst currently has no concept of "top file". It's something I'd like to rectify though.
Is it not listed in the port selection menu or does it just not connect to it when you as it to?
An intermittent detection issue. Is it a prop-plug or ftdi converter? The last 3 pre-releases have had a *very* short reset pulse to try and help those using transistor RS232 converters. I might have made it a whisker short. How often does it do it?
No, should not matter where you put bst. On windows it stores its settings in the registry. (HKCU\Software\camsoft\bst\v0.1) or something like that.
Have a look at the "CompilerSearchPath" key and see what is there.
Awkward. What concerns me is people trying to use a pre-compile step to modify or pre-process source files prior to the compiler getting its grubby little hands on the source, because if the source is open in a tab the compiler sucks it straight from RAM and bypasses the disk entirely, so the behaviour may be confusing and inconsistent.
@dossic, yes. Sending Ctrl characters is planned. In the mean time, the latest pre-release snapshot allows you to send raw hex using the hex window, so you can send those characters directly. It's not as friendly, but it is possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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'm using Parallels and Windows XP to utilize the PropTool,and those tools to debug my programs. I'd be lost without them; PASD to debug initially the PASM cogs and ViewPort to verify the timing with the hardware the Props interface with.
I just realized there are some 50+ pages of responses to this thread. Thus I'd prefer not to start reading from the beginning of this thread.
Is there a summary of what this application does/does NOT provide?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Other than what is in the preliminary manual and detailed on the download page, not really.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
"What concerns me is people trying to use a pre-compile step to modify or pre-process source files"
Well, yes that's the point [noparse]:)[/noparse] In my case it's not changing a "text" source though, it is changing a "binary" that is included with the dat file "filename.bin" statement which is taken from the disk ... I guess someone could be silly enough to have that open in the editor though. I guess the McDonald's quality strategy analogy is necessary.
I'm fine with using BSTC in a script after compiling my binary with other tools, but the automatic serial port coordination goes away with that. Automatic serial port coordination is a major motivation for me to use BST on Windows.
The com21 and library path issues seem to have gone away.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
mumble..mutter...read..forum..mumble..mutter..gripe..
I bet they never had this problem in the old days when you needed to understand how a machine worked to be able to use it! [noparse];)[/noparse] Abolish the web. Bring back gopher!
I'll admit the serial terminal is a neat feature. Especially so since Cluso99 made me re-focus the terminal after a good load. Best thing I've done all year.
I'll look into how I might achieve it cleanly. I'm already launching PropBASIC in a cross-platform manner, so it can't be *that* hard. It would likely be a project option only (Don't want someone setting a global up by mistake), but it'd then be managed in the project file. I can't promise it'll be a quick fix though. I'm pegged for a week or two. (gotta do real work to pay for bst development).
Intermittent faults <grumble>
The -pre versions of bst have not been validated for release, and I've made significant blind timing changes to the loader recently (CRO is packed somewhere). I need to build a board that will let me plug an RS232 port in to test the issues with the transistor circuit on all my platforms before I run the loader validation tests. Intermittent failures would not surprise me right now as the reset pulse is *very* short (<2mS). I've just not had time to build the discrete RS232 interface to test with.
I'd actually like to be able to test with DTR / RTS resets in both polarities, but I need to get a bit clever and design a board for it I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 can certainly live with a per-project option for using pre-build commands.
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
just in case you're without anything to do, which I can't imagine, here's a suggestion regarding the warnings printed with -w2:
If a #-less jump's target is a ret instruction, the warning is superfluous, because you get what you expect. I don't know if your compiler has the opcode that is jumped to in reach to verify with 'ret', so it might be too complicated to suppress the warning in this specific case. Perhaps a compare for the target label ending with '_ret' is sufficient, though some very brain dead people might use xxx_ret for an address that has no ret instruction.
Did I ever say Thank you for bst(c)? Thank you!
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 4/29/2010 1:30:38 AM GMT
Notable features / fixes :
- Cmd-]/[noparse][[/noparse] block indent/outdent for Mac (I hope)
- Basic/Simple Syntax highlighting for PropBasic (Configure the text/background colour in the IDE Prefs menu)
- Pre-Compile binary execution for a project (in the project options box). Put the full file path/name and command line in the box. bst will complain loudly when you try to compile if you've got it wrong.
Now.. I really, really, really need feedback from Mac and Linux users on the next one.. pretty please with sugar on top.
When you right click on a tab in the tab bar at the top, the first item in the context menu should be the name of the tab you've right-clicked on. In previous versions it has always been the name of the currently showing tab. This should now properly work with any tab you click over.
The advantage of this is 2 new menu entries in that menu. "Move Tab Left" / "Move Tab Right". Provided the context menu shows the correct tab when you right-click on it, you can move your tabs around (slowly mind you).
This has the potential to go horribly wrong, and it was unreliable until very recently in the underlying tools (Lazarus LCL), which is why I had it locked to the currently open tab. I've tested this on Win32, Linux GTK2 & OSX 10.6.2 Intel.. I really need people with older versions of OSX to test it for me, and PPC users if possible. Open lots and lots of tabs (far more than will fill the screen) and scroll around the tabs right clicking on each one. If the name at the top of the menu is not the same as the tab you right clicked on then we still have a problem and I'll have to revert the behaviour.
<edit> this has been built and uploaded on my laptop as my ADSL is down, so I'm not sure entirely of the stability of this tool chain for Win32 & OSX.. be warned.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
THANKS for highlighting possibility's to .pbas - BUT I have one dumb question on that.
Istead of have highlighting inbuilt in BST - What about lift them out to separate INI files highlighting.PASM, highlighting.SPIN, highlighting.PBAS, highlighting.C and so on.
That can give possibility's to USE BST even to edit other types of Files that are used with Programing PROPELLER.
On my XP moving TABS mostly function but not always In some cases I need first go to Tabs window and activated cursor in it before it will move TAB.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I can honestly say that getting the nuances required for good spin highlighting is beyond a simple .ini file and really requires a dedicated highlighter (the highlighter in bst is still getting some bits wrong). The highlighter has to be able to basically parse the source file so it knows which block it's in at any point. It's a bit complex, particularly with the block based folder.
The basic highlighter is quite a bit simpler right now. I could split that out into a separate file, but that then becomes a bit more complex than the "unzip and go" that I'm aiming for with bst.
Yes, but why would you want to? bst is written to compile spin and basic files in the simplest way possible. It can't currently talk to other third party compilers and it's missing a stack of features I'm sure you'd find in real editors.
I have noticed one irregularity where if you are moving a tab that is not the active one things get odd. The tabs all wind up where you want them to, but odd tabs get selected and focussed at the same time.
Thanks for the feedback [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Thanks for the PropBasic highlighting. Very cool.
I've noticed a couple keywords that don't get highlighted.
I assume you used the words in the RESERVED.TXT file ?
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
Yes I did, but it's entirely possible I bolloxed bits of it up. I only put it together about an hour before I uploaded it, so It's sure to have broken bits. I just wanted to get it out there for testing and comment so I can refine it before the 0.19.4 release goes out.
As always, suggestions very welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
HUB, STR, P8X32A are what I've found so far.
I'd add any keywords to RESERVED.TXT for the next release.
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information