I had been away from Propeller for some time and only really got back to it a month or two ago, so I was really excited to see about the Macintosh development of the BST. To make a long story short, back around Christmas I started to put the pieces together and get it running on my iMac running under Snow Leopard. However, the documentation, what there was of it, was at best, OK. I still had lots of niggling little questions. Brad weathered a dozen or so emails from me and got me pointed in the all right directions. I decided to chronicle my efforts with extensive screen shots etc and the result is here as an AppNote on my website -- www.wulfden.org/TheShoppe/prop/AN-PROP001.shtml -- I sent the link to Brad. He liked it and suggested that I post it here.
cheers .... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden www.wulfden.org/TheShoppe/
Post Edited (Brian Riley) : 1/6/2010 6:02:27 AM GMT
This *should* be the last bug fix test release before 0.18.5,*HOWEVER*, I've just upgraded my entire toolchain and build environment to the latest release FreePascal compiler (a major and quite disruptive upgrade), *SO*, can people who are affected by this release and those experienced with broken bst bits test this one for me and see that it behaves? It's all good here, but of course it always is!. Please don't delete your old releases, just in case. This is a major, major back end update and there have been some not-insignificant code shuffles in bst to get it to compile properly. It's all very, very new.
James, I have fixed the "Find" thing. It will either insert the currently highlighted selection *or* whatever word the cursor happens to be in the middle of. This is worth the upgrade alone!
Bob, I'm pretty sure I've fixed the geometry issue that causes it to go haywire when you put it on your left hand screen.
Toby, this may well fix the strange maximise/minimise thing you've seen going on also.
Oh, while I'm here. The OSX build is always quite large (due to it being a fat binary). Are there many people who actually use both Intel and PPC Mac's (aside from me) and get value from the fat binary? I've been having passing thoughts about breaking it up into a PPC and Intel version. That would actually create more work for me, but it would mean smaller downloads for Mac users who only needed one of the architectures.
As always, feedback gratefully received.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Just going back over your posts regarding operator warnings. Great idea, and I'd be happy to look at any suggestions you have as to where to generate warnings. Can one (or both) of you maybe jot down a bit of a quick list of what operators in what context would be worth warning against?
I see >= and <=, and I can understand those (they bit me in the early days too). Should they warn *all* the time?
If A := B is a bit more of a special case. I'm a bit torn. Do we warn any time := is used where it's not the primary assign function ?
For example : A := B := C. Do we warn on the B := C bit?
Do we create an extra warning level number to indicate we want warnings on potential valid but confusing SPIN operators ?
At the moment we have
-w0 - Errors only
-w1 - Errors + Warnings
-w2 - Errors + Warnings + Information (Unused local/global variables - unused SPIN methods)
Do we add :
-w3 - Errors + Warnings + Information + "Traps for young players" ?
Do we make a JMP without "#" a "Trap for young players" ? The JMP is a potential pitfall that grabs *lots* of people and does not come up as a valid construct very often, but do we want to clutter the warnings with every use of >=/<=/:= where they are all potentially valid ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
For warnings I'd vote for a mechanism to turn them off selectively from the source. A magic comment or some such.
Warning messages do not work if you can't suppress the ones that are bogus.
matb said...
For warnings I'd vote for a mechanism to turn them off selectively from the source. A magic comment or some such.
Warning messages do not work if you can't suppress the ones that are bogus.
I prefer the #warnoff as it is more meaningful to new players.
I concur with the jmp-immediate parameter.
However, I am thinking of another possibility. I have 3 jmp #xxx instructions in ZiCog which are valid. The warning showed me two other errors, so I love it. Now, if the comment on instruction line(s) causing warning messages were to begin with '# (or '! or other???) could this be used to ignore the line for a warning message? This way, when we originally run the code with the warnings on, we can see what are errors and what are real. Just update the comments on those that are real, and voila, we have hidden them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
BradC said...
Would you like to propose some more syntax though?
OK, I'm not entirely up-to-date re: variables, I assume it's about un/used? Feel free to add the word warning to the switch names if you think that makes it easier to understand/remember.
A further decision needs to be made whether we want those switches be set once (to override the default behaviour) or be able to switch a warning (repeatedly) on/off within a source file. I think we can get away with the global override, the latter seems too much like overkill for what we are trying to achieve.
I hate that word "pragma", just a personal thing I know.
I like Cluso's and matb's idea. Just some thoughts:
1) Lets say we have warnings when "odd" things are going on intentionally. Jumps without # etc etc
2) As pointed out warnings don't work if you can't turn them off, there might be enough that people give up checking them all.
3) It seems to have become a standard practice to put a little note in the comments to remind people of "odd" things going on. So formalizing that with a "magic" comments might me a good idea.
4) The use of #warn_off prior to such an "odd" statement would have to be balanced with a #warn_on following it, at which point the whole mechanism gets a bit overweight and messy to my mind.
#warn_off
jmp pointer 'No # here as because...
#warn_on
5) Doing it as shown above carries the risk of the warn_on being accidentally omitted thus discarding all following warnings that may be in the code. Not good.
6) A magic comment could use a simple "!" following the comment marker, say
jmp pointer '! Intentionally jumping though a register here
7) For those hairy chested real programmers who don't want warnings and never comment code a single global warnings on/off switch in project setting is probably good enough.
8) Leads me to think that a "magic" comment that follows a "non-odd" statement should generate a warning. Or is that getting too weird?
By the way I'd still like to have a warning for labels that never get references in PASM in anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok, magic comments or anything other than global one off defines are _really_ not easy to achieve with the current architecture.
The compiler tokenises the source, disposes of all comments and deals with pre-processor details prior to the token chains being passed to the compiler, so line specific stuff is really going to require a lot of re-factoring.
I could do per-file #warn_off or similar for specific warnings fairly easily I think.
I find the warnings useful, but I guess I'm used to just scrolling past them to see what jumps out. After a compile or two you get used to where and what they are.
heater, I'm with you. I really don't like #pragma either.
Warning labels for unreferenced asm symbols are certainly doable. I'll pop it on the list if you like.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I use BST on Intel Macs only. I really do not care about the fatness of the BST executable. I do not have an opinion with the warnings thing. I really hardly use spin, so I do not count. I'll test this version and see if I find something. Thanks again and again.
With my, very limited, experience of trying to write compilers I already started to think that "magic" comments might be a bit tricky.
So why not just go with #warn_off and #warn_on, it's more verbose and a little risky but it is very clear in it's intention when you see it in the code. The magic comment thing "'!" migh be looking like more syntactic "line noise" to some.
A global off switch in settings is good enough as well isn't it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So why not just go with #warn_off and #warn_on, it's more verbose and a little risky but it is very clear in it's intention when you see it in the code.
What I was trying to say is at the moment '#xxxx' are all handled in the tokeniser, so there are no tokens for that passed down into the compiler.
Having all warnings on by default (display them with -w > 1) and turning them off individually with a #warnoff jmp-immediate in the source would be _relatively_ achievable though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Brad, is there any chance to display the comments with the warning messages? (my comments for the jumps without # have a comment identifying it is correct)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Brad, is there any chance to display the comments with the warning messages? (my comments for the jumps without # have a comment identifying it is correct)
Actually, I've been back and had a closer look at the source/list generator code, and there might be a hacky way to do it, although I still think it's ugly and ungainly.
If you put a comment anywhere on the line that will generate the warning and use '!W (three consecutive characters, no spaces and a space either side).. so
jmp w0 '!W <- this turns the warning off this line.
Just tested it with the below code and it worked ok.
DAT
rtoken long 0
cmp rtoken, #10
nop
jmp label '!W This disables the warning
label
PUB Start
This applies to any warning. (org/fit/data after res) and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
And there you were explaining to me that it was almost impossible to do[noparse]:)[/noparse]
Lets see how people like it.
Does it need to require a space before? This contrary to normal syntax.
Does it require a space after? That's a shame as I can't write:
jmp label '!Warning: Jumping through label, no #.
Still I think it's quite neat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I could live with out the warn_off/on. Conceptually it seems better but looking at it it's to much bulky text detracting from what's going on. A few of those on a page of code would make a really ugly looking mess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This is going to seem like a *really* dumb question, but where do I get the latest version?
I tried here www.fnarfbargle.com/bst/ but the versions peter out in July 2009. I tried clicking the link Jan15 (it is Jan15 today) but that is just a picture. Am I in the right place, or is there another place for downloads?
Nice new program. Auto fits in the screen and also the Highlight/Find is working brilliantly.
However, I can't seem to get it to load programs. It compiles, then waits about 10 seconds, then says "Propeller Loader Crashed" and hangs.
Right, that's probably related to the changes I had to make to get it to compile under the new toolchain. I've not had a Windows machine to test on. Let me see what I can do.
<edit>
Yep, serial is broken under Windows. Gimmie half an hour to figure out what I broke [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Turns out it was not something I broke, but the serial library I've been using for the windows stuff exhibits different exception behaviour under the new compiler. Who'da thunk it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Comments
cheers .... BBR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The Shoppe at Wulfden
www.wulfden.org/TheShoppe/
Post Edited (Brian Riley) : 1/6/2010 6:02:27 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
This *should* be the last bug fix test release before 0.18.5,*HOWEVER*, I've just upgraded my entire toolchain and build environment to the latest release FreePascal compiler (a major and quite disruptive upgrade), *SO*, can people who are affected by this release and those experienced with broken bst bits test this one for me and see that it behaves? It's all good here, but of course it always is!. Please don't delete your old releases, just in case. This is a major, major back end update and there have been some not-insignificant code shuffles in bst to get it to compile properly. It's all very, very new.
James, I have fixed the "Find" thing. It will either insert the currently highlighted selection *or* whatever word the cursor happens to be in the middle of. This is worth the upgrade alone!
Bob, I'm pretty sure I've fixed the geometry issue that causes it to go haywire when you put it on your left hand screen.
Toby, this may well fix the strange maximise/minimise thing you've seen going on also.
Oh, while I'm here. The OSX build is always quite large (due to it being a fat binary). Are there many people who actually use both Intel and PPC Mac's (aside from me) and get value from the fat binary? I've been having passing thoughts about breaking it up into a PPC and Intel version. That would actually create more work for me, but it would mean smaller downloads for Mac users who only needed one of the architectures.
As always, feedback gratefully received.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Just going back over your posts regarding operator warnings. Great idea, and I'd be happy to look at any suggestions you have as to where to generate warnings. Can one (or both) of you maybe jot down a bit of a quick list of what operators in what context would be worth warning against?
I see >= and <=, and I can understand those (they bit me in the early days too). Should they warn *all* the time?
If A := B is a bit more of a special case. I'm a bit torn. Do we warn any time := is used where it's not the primary assign function ?
For example : A := B := C. Do we warn on the B := C bit?
Do we create an extra warning level number to indicate we want warnings on potential valid but confusing SPIN operators ?
At the moment we have
-w0 - Errors only
-w1 - Errors + Warnings
-w2 - Errors + Warnings + Information (Unused local/global variables - unused SPIN methods)
Do we add :
-w3 - Errors + Warnings + Information + "Traps for young players" ?
Do we make a JMP without "#" a "Trap for young players" ? The JMP is a potential pitfall that grabs *lots* of people and does not come up as a valid construct very often, but do we want to clutter the warnings with every use of >=/<=/:= where they are all potentially valid ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Warning messages do not work if you can't suppress the ones that are bogus.
Something like :
#warnoff globalvars
#warnoff localvars
#warnoff spinoperators
#warnoff jmp-octothorpe
??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Nope. Would you like to propose some more syntax though?
Sure it can. No worries.
I'm not wedded to any syntax or solution and suggestions are most welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I concur with the jmp-immediate parameter.
However, I am thinking of another possibility. I have 3 jmp #xxx instructions in ZiCog which are valid. The warning showed me two other errors, so I love it. Now, if the comment on instruction line(s) causing warning messages were to begin with '# (or '! or other???) could this be used to ignore the line for a warning message? This way, when we originally run the code with the warnings on, we can see what are errors and what are real. Just update the comments on those that are real, and voila, we have hidden them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
A further decision needs to be made whether we want those switches be set once (to override the default behaviour) or be able to switch a warning (repeatedly) on/off within a source file. I think we can get away with the global override, the latter seems too much like overkill for what we are trying to achieve.
I like Cluso's and matb's idea. Just some thoughts:
1) Lets say we have warnings when "odd" things are going on intentionally. Jumps without # etc etc
2) As pointed out warnings don't work if you can't turn them off, there might be enough that people give up checking them all.
3) It seems to have become a standard practice to put a little note in the comments to remind people of "odd" things going on. So formalizing that with a "magic" comments might me a good idea.
4) The use of #warn_off prior to such an "odd" statement would have to be balanced with a #warn_on following it, at which point the whole mechanism gets a bit overweight and messy to my mind.
#warn_off jmp pointer 'No # here as because... #warn_on5) Doing it as shown above carries the risk of the warn_on being accidentally omitted thus discarding all following warnings that may be in the code. Not good.
6) A magic comment could use a simple "!" following the comment marker, say
jmp pointer '! Intentionally jumping though a register here7) For those hairy chested real programmers who don't want warnings and never comment code a single global warnings on/off switch in project setting is probably good enough.
8) Leads me to think that a "magic" comment that follows a "non-odd" statement should generate a warning. Or is that getting too weird?
By the way I'd still like to have a warning for labels that never get references in PASM in anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The compiler tokenises the source, disposes of all comments and deals with pre-processor details prior to the token chains being passed to the compiler, so line specific stuff is really going to require a lot of re-factoring.
I could do per-file #warn_off or similar for specific warnings fairly easily I think.
I find the warnings useful, but I guess I'm used to just scrolling past them to see what jumps out. After a compile or two you get used to where and what they are.
heater, I'm with you. I really don't like #pragma either.
Warning labels for unreferenced asm symbols are certainly doable. I'll pop it on the list if you like.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I use BST on Intel Macs only. I really do not care about the fatness of the BST executable. I do not have an opinion with the warnings thing. I really hardly use spin, so I do not count. I'll test this version and see if I find something. Thanks again and again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So why not just go with #warn_off and #warn_on, it's more verbose and a little risky but it is very clear in it's intention when you see it in the code. The magic comment thing "'!" migh be looking like more syntactic "line noise" to some.
A global off switch in settings is good enough as well isn't it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
What I was trying to say is at the moment '#xxxx' are all handled in the tokeniser, so there are no tokens for that passed down into the compiler.
Having all warnings on by default (display them with -w > 1) and turning them off individually with a #warnoff jmp-immediate in the source would be _relatively_ achievable though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
anywhere in a module would turn that class of warning off for that module. Sounds OK to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Actually, I've been back and had a closer look at the source/list generator code, and there might be a hacky way to do it, although I still think it's ugly and ungainly.
If you put a comment anywhere on the line that will generate the warning and use '!W (three consecutive characters, no spaces and a space either side).. so
jmp w0 '!W <- this turns the warning off this line.
Just tested it with the below code and it worked ok.
This applies to any warning. (org/fit/data after res) and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
a '!W (and yes it's case sensitive) on a line will suppress any warning that might have been generated from that line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Lets see how people like it.
Does it need to require a space before? This contrary to normal syntax.
Does it require a space after? That's a shame as I can't write:
Still I think it's quite neat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually, it does not require a space before or after, so your example will work.
The bit I was trying to convey would be extremely difficult was
#warn off jmp fred #warn on▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I could live with out the warn_off/on. Conceptually it seems better but looking at it it's to much bulky text detracting from what's going on. A few of those on a page of code would make a really ugly looking mess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I tried here www.fnarfbargle.com/bst/ but the versions peter out in July 2009. I tried clicking the link Jan15 (it is Jan15 today) but that is just a picture. Am I in the right place, or is there another place for downloads?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Nice new program. Auto fits in the screen and also the Highlight/Find is working brilliantly.
However, I can't seem to get it to load programs. It compiles, then waits about 10 seconds, then says "Propeller Loader Crashed" and hangs.
I've gone back to the 20th July 2009 version for the moment. Any help would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Right, that's probably related to the changes I had to make to get it to compile under the new toolchain. I've not had a Windows machine to test on. Let me see what I can do.
<edit>
Yep, serial is broken under Windows. Gimmie half an hour to figure out what I broke [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Post Edited (BradC) : 1/15/2010 10:59:37 AM GMT
Turns out it was not something I broke, but the serial library I've been using for the windows stuff exhibits different exception behaviour under the new compiler. Who'da thunk it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.