What if you had an object which which handled various text/graphics functions for video
(perhaps Baggers Spectrum driver, or Jetfires Graphics mod) and created a special
subset of commands which could integrate with spin in your compiler for new users,
or for those looking to create quick software?
You could implement some BASIC or PBASIC commands using PRINT/INPUT which
BST could look for on the fly and import the proper object from the library.
Something tells me this idea of "polluting" a spin compiler will draw some heated
discussion from someone, but I can imagine a number of users would use the feature
as a stepping stone into spin if it were there..
Heck with few chunks of spin code, a BASIC/PBASIC compiler mode could be created.
(Not sure this is a project you would want, but like I said.. It's thought to chew on..)
Reflecting on this reply, I suspect I've suggested another heresy and need to be
ducking chairs soon..
Ken throws a shoe at Old Bit Collector and reaches down for the other one....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
What if you had an object which which handled various text/graphics functions for video
(perhaps Baggers Spectrum driver, or Jetfires Graphics mod) and created a special
subset of commands which could integrate with spin in your compiler for new users,
or for those looking to create quick software?
You could implement some BASIC or PBASIC commands using PRINT/INPUT which
BST could look for on the fly and import the proper object from the library.
Something tells me this idea of "polluting" a spin compiler will draw some heated
discussion from someone, but I can imagine a number of users would use the feature
as a stepping stone into spin if it were there..
Heck with few chunks of spin code, a BASIC/PBASIC compiler mode could be created.
(Not sure this is a project you would want, but like I said.. It's thought to chew on..)
Its interesting you bring this up. I've been playing with and pondering the addition of a "BAS" block with a PBASIC syntax-ish style. I had envisioned a helper cog, perhaps in an LMM style that dropped pre-defined blocks together, something along the lines of SX/B to enable a "BASIC" on the Propeller. So I don't believe we are way out of line in our thinking.
Unfortunately, due to personal circumstances (as I hinted at on IRC) I'm going to be short of time and resources for a couple of months (read as my compiling machine and related infrastructure is going to be packed in boxes somewhere on a ship in the Indian Ocean for a month or two), so while a bit of hacking and playing might be in order (time permitting), anything more serious may have to wait a couple of months.
As of about the 7th of Jan, my ability to get to the forums is going to be severely impacted for a month or so.. so while I'll check when I get the chance, reply time is going to be limited.
I am trying to get a bugfix of bst out before I get packed up, but I'm afraid it's likely to be just a bug fix.. the features I had planned might have to wait a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Ken Peterson said...
WHAT???? BASIC on the PROPELLER???
Ken throws a shoe at Old Bit Collector and reaches down for the other one....
A Shoe?!? Who throws a shoe? I mean really.....
Aside from the above quote, the local paper here held a poll.
Should he
A) Be sent to prison Be released
C) Be lauded as a hero
D) Rewarded with a new pair of shoes.
... D got over 40% of the votes [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
BradC and Oldbitcollector,
Here's a previous thread where I mentioned a native Prop compiler-compiler and the beginnings of a Basic compiler. I really have not worked on it much since this was posted other than to look at the possibility of compiling into Spin byte codes rather than LMM object code. The main issue is that it was written as a single program and it needs to be split into separate passes instead. To support that, I was trying to expand Rokicki's SD card routines to allow for multiple open files (and subdirectories). I ran into problems and just haven't been motivated to plow ahead. The dictionary works and variable allocation works. Some of the code generation works as well. I've now got a Demo Board set up with 512K bytes of EEPROM (4 x AT24C1024B) and I'll use that instead of the SD card to try to move ahead. The intention was to provide some kind of native program development platform other than FemtoBasic and Forth, preferably reasonably fast.
Brad - You need a laptop for the boring times on the ship Then you can do some code for the rest of us, not that we are greedy or anything, but why should you have time off???
Ken: At least your shoes are easier to use that your phone and computer, but don't tell the shoe manufacturer - you know what they did to Maxwell Smart's shoes!!
Now back to reality. It was only last night that I was chatting with baggers (I misunderstood a statement). I suggested that there is room in my ClusoInterpreter (not finally debugged because I got sidetracked - building a prop in a Spartan 3A FPGA) to possibly add LMM. Basically I have LMM (basic style) currently in my interpreter (as a zero footprint debugger). Anyway I said to baggers that we would need the compiler to be modified for this and there are two versions out there that the writers could modify.
One caveat - LMM variables have to be in hub unless the ClusoInterpreter is specifically compiled with overlays, or with features removed.
What do you all think?? Worth a new thread: "Embedded support for LMM in spin" ??
Cluso99 said...
Brad - You need a laptop for the boring times on the ship Then you can do some code for the rest of us, not that we are greedy or anything, but why should you have time off???
I'm not going on the ship, just my furniture and infrastructure. I have the laptop and I can cross compile for all platforms from there, but I can't test anything other than Linux from the laptop until my Mac reaches dry land. I'll be working in the background, , but I have work lined up back in Aus that is going to keep me pegged until things settle down "Feb(ish)"
I like the idea of adding LMM support to the compiler. It has always been my aim once things got stable to add extra features like that, but then bst came along and sidetracked me. I think with the latest round of fixes the compiler is starting to stabilize and I have a versatile base from which to look at adding enhancements. I just need to sit down with someone and dedicate some time to understanding precisely what it is that you have in mind and how it needs to be put together, and I'm not going to have that time until I get Jan/Feb out the way and get settled back in a sane country. (Tax laws notwithstanding).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Maybe just adding some macro support can help with the LMM support.
I'm writting a simple user interface, config panels, with 4 or 5 "controls". All drawing is made native in pasm, user inut and responses are done in LMM: relative jump, constant loading, subroutine call to LMM code, just 5 routines. It gets... complicated I mean there are loads of:
call #krnl_loadcnt
long @k4_cnt_FONT+(krnl_r0<<26)+16
call #krnl_call
long @lmm_config+16
and other niceties (with the scheme I proposed some time ago). but, it works . Some macros could easily help and make the code a bit more flexible without fixing the compiler to a specific lmm type. (I thought for my compiler to do some sort of find-and-replace method, just for simplicity).
The LMM (interpreter) that I implemented in the debugger uses 5 longs: 4 for the loop and execution and 1 for data. However, the actual LMM code is more complex because it has to take care of jumps.
A call to an LMM routine would make sense for the interpreter to implement. The completion of the LMM would then just be another fixed call to return to the interpreter. I could see this as being relatively easy to implement from both the interpreter and the compilers perspectives. The main complexity is the fact that mov instructions will not work as expected because variables are not in cog memory. This means it is not true LMM, but a variant or subset. However, I could see some real speed advantages of mixing spin and LMM.
Postedit:· New thread...
Embedded support for LMM within SPIN (discussion & proposals)·
Mike Green said...
BradC and Oldbitcollector,
Here's a previous thread where I mentioned a native Prop compiler-compiler and the beginnings of a Basic compiler. I really have not worked on it much since this was posted other than to look at the possibility of compiling into Spin byte codes rather than LMM object code. The main issue is that it was written as a single program and it needs to be split into separate passes instead. To support that, I was trying to expand Rokicki's SD card routines to allow for multiple open files (and subdirectories). I ran into problems and just haven't been motivated to plow ahead. The dictionary works and variable allocation works. Some of the code generation works as well. I've now got a Demo Board set up with 512K bytes of EEPROM (4 x AT24C1024B) and I'll use that instead of the SD card to try to move ahead. The intention was to provide some kind of native program development platform other than FemtoBasic and Forth, preferably reasonably fast.
I'd love to have a look at this Mike, but I can't find a link. Can you point me at the code so I have something to chew on over Christmas perhaps?
I was thinking originally about a BASIC compiler targeting SPIN bytecode but with a "helper cog" to provide some of the stuff the BASIC STAMP interpreter does, perhaps in LMM.
I'm not familiar with the STAMP at all. The Propeller is my first Parallax product, but I've read the BS2 manual and was thinking it might be fairly doable to provide a reasonable PBASIC style compiler (with assistance from a helper cog) to allow people an avenue to port their BS2 code directly to the Propeller (of course without the multi-tasking aspects that SPIN provides). Then I had a look at SX/B and thought that might be a nice idea also in LMM mode. Toys, lots of toys....
tpw_man and I were talking about building a BS2 emulator directly so people could use the BS2 tools and just "download" an image directly to the Propeller (Make the Prop look like a BS2), but he's been quiet of late and I've had a few other things on my plate (actually, to be honest I was all talk and he seemed keen to get into it).
I've been thinking harder about a SPIN compiler on the propeller. What I know about compilers can be written on the head of a pin. My first ever crack at it was bstc and I'm not incredibly proud of that code (it does seem to work though). I think with a bit more thought and a more educated approach, it might be possible to make it work on the propeller. It'd be as slow as a wet week in May, but it might just work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
First things first. These are the things I have NOT managed to work into this release. Sorry..
Remaining TODO Items :
- Clicky http:// links in source (Chuck Rice)
- Beep and triple flash for find/replace (Chuck Rice)
- Configurable colours (TChapman)
- Configurable keystrokes (Lots of people)
- Folding fix for blocks that have the BLOCK then a COMMENT in series. ie. PUB {{ (Chuck Rice)
- Block indicators (Practically everybody)
- Allow immediate compilation of a crash-recovered source file without saving first (Oldbitcollector)
Changelog in top post as usual.
OBC has been working overtime with this release feeding me great bug reports and I thank him for his patience with a crashing program. Linuxvolts was kind enough to E-mail me his code that was breaking things also. I can assure you all that any code you do send me remains completely confidential and I appreciate those that have taken the time to both report bugs and send me test cases to improve my code.
Now, I've made changes to the way ports are allocated after Ken Peterson spotted a bug on Windows (I assume it was windows as he mentioned COM4).
I may or may not have fixed this adequately. As a work-around you can always set the port manually in the ide prefs dialog, and I'd like to know if it's not fixed properly please.
If you do accidentally manage to set a port you did not want to, you can always default the auto-scan behaviour by using the IDE options and setting the port to "Auto".
At the suggestion of Ken, I've added "Project specific overrides". Each project file can be edited in the "Project Options" menu, which will allow you to specify project-specific search paths and compiler optimisation options. Please note that if you have *any* path in the project specific dialog, it disables and overrides the globally set search paths. To disable this, just remove all the paths in the project options.
The project additions have been "lightly tested". Please beat on them (Save first as if there _is_ a bug it's likely to be a crasher)
I've added options to set the tab width and disable smart tabs for Jay. I've left smart tabs functional for backspace and delete. Let's see how that behaves anyway before I make any major changes.
I think I've addressed all bugs and suggestions bar what is in the TODO above. Please keep shouting at me if I miss stuff and I'll get to it as soon as I can.
I have _not_ tested this anywhere as extensively as I usually do prior to a release. I'm sorry guys but I just don't have the horsepower right now. It has been lightly tested on Linux, OSX and the Win32 version under WINE.
Baring anything catastrophic over Christmas, this will likely be the last release until Feb. I have a one way ticket booked on the 4th of Feb, the development hardware and machines go into a box in the first week of Jan and I won't be able to really do much until mid Feb when they land (Unless I can con the SO to allow me to pack my Macs in the suitcase!)
Have a great Christmas everyone and a happy New Year!
(OOPS, forgot to mention the compiler is 10% faster again)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Just spotted a bug to be aware of. When closing bst or closing a project, if you have a project open it will save all editor tabs without asking you. If you have changes you don't want saved this can be bad. I'll make sure its fixed in the next release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I just downloaded the new release (OS X). Thanks for adding the custom tabs. I'm having a problem though. I can no longer add a compiler search path. Well, BST allows me to add it, but it doesn't stick. So I get compiler warnings when I try to compile files that aren't in the same folder as the top object.
Jay Kickliter said...
I just downloaded the new release (OS X). Thanks for adding the custom tabs. I'm having a problem though. I can no longer add a compiler search path. Well, BST allows me to add it, but it doesn't stick. So I get compiler warnings when I try to compile files that aren't in the same folder as the top object.
Jay
Ok, I can see where I broke it but I can't fix it at the moment.
Workaround would be to use an older version of bst to set the path and then don't open that dialog again until I can get a fix out.
Sorry..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Cheers OBC [noparse]:)[/noparse] Just be careful with the compiler search paths as Jay found. I've fixed it but as I'm at an internet cafe in Qatar I'm unable to build and upload a fixed release at the moment.
The server I upload my stuff to is Co-Lo in the UK, so there is no chance of it going offline while I'm moving. Thanks for the offer though [noparse]:)[/noparse]
I've fixed both the bug Jay spotted, and also the problem with it auto-saving on close when not asked to. I'll try and get a new release built via my server at home in the next day or two, but with the Undersea cables cut my bandwidth is very limited and incredibly unreliable. They have said they'll get them fixed by the 27th of Dec though.
ssh sessions are painful when your ping times randomly alternate between 300m and 5000ms with a 50% packet loss.. [noparse]:([/noparse]
Have a Merry Christmas all [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I thought there was an option to prevent BST from starting a new document upon start-up, but I can't find it. Am I imagining it?
There is no option to prevent that happening, however it's only supposed to happen when no other file is being opened on startup. So if you start bst by opening an associated file, or its doing a crash recovery, or you are opening with the "open last project" option then it should not create a blank page.
I'm sure I can add that as an option at some point though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
A straight day of coding and the editor is working perfectly. Looks like you've also addressed some of the timing issues at compile, as I'm seeing very few "lost propeller" during transmission issues.
Have any other OS X user had a problem setting BST as the default application associated with .spin files? It just wont stick for me, but I can set any other app to be default.
The only thing left bugging me is that daily when you click the tab at the bottom to bring the program forward (PC), the screen never draws, you have to click the tab a few times to get it to appear. I can't remember at the moment if this is related to the computer coming back from sleep or not.
Jay Kickliter said...
Have any other OS X user had a problem setting BST as the default application associated with .spin files? It just wont stick for me, but I can set any other app to be default.
Ok, I've tracked this down to a booboo in my Info.plist file. I've attached a replacement. Just pop it in bst.app/Contents to replace the existing Info.plist.
That should fix the file association problems for you. Please yell if it does something other than what it should. I've told it to make bst the default app for spin/eeprom/binary files. I'm not sure how tenacious that is but you *should* be able to change the association away from that if you need to.
In any case it shows you how green I really am at OSX development [noparse]:)[/noparse]
I've looked a bit closer at the problem where it always seems to open a new blank file on startup, but due to the way I've built things it's going to take me a little while to re-factor some code to fix it. I'll make sure it's in the next feature release anyway (I'm hoping not to have to make any bug-fixes between now and then, but you never know!)
@TChapman, I can't reproduce this here. Do you mean the program marker on the task bar in Windows? Are you using XP or Vista? I'll try to get it reproduced and fixed in any case.
When I get to Aus next week I'll have a couple of XP machines and a Vista machine to play with for a week or so, so I can give it a proper look over (I test inside a VirtualBox VM here)
sevs brought an interesting bug on windows to my attention on irc. Sometimes depending on windows version it's not properly picking up the proper location to store the recovery file and you get a message "Unable to save recovery to /.bst.recover". Are any other windows users seeing this issue? (Are there any other windows users?)
@Oldbitcollector, So glad it's working for you now. Interestingly enough I've not made _any_ changes at all to the propeller download code for about 3 releases now. I have some new bits planned to try and speed up the download, but they will have to wait until about mid - Feb I guess.
Happy new year all. I hope the financial crisis sees you all healthy and employed [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Comments
I've got a thought for you to chew on...
What if you had an object which which handled various text/graphics functions for video
(perhaps Baggers Spectrum driver, or Jetfires Graphics mod) and created a special
subset of commands which could integrate with spin in your compiler for new users,
or for those looking to create quick software?
You could implement some BASIC or PBASIC commands using PRINT/INPUT which
BST could look for on the fly and import the proper object from the library.
Something tells me this idea of "polluting" a spin compiler will draw some heated
discussion from someone, but I can imagine a number of users would use the feature
as a stepping stone into spin if it were there..
Heck with few chunks of spin code, a BASIC/PBASIC compiler mode could be created.
(Not sure this is a project you would want, but like I said.. It's thought to chew on..)
Reflecting on this reply, I suspect I've suggested another heresy and need to be
ducking chairs soon..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Post Edited (Oldbitcollector) : 12/20/2008 4:49:17 PM GMT
Ken throws a shoe at Old Bit Collector and reaches down for the other one....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
Its interesting you bring this up. I've been playing with and pondering the addition of a "BAS" block with a PBASIC syntax-ish style. I had envisioned a helper cog, perhaps in an LMM style that dropped pre-defined blocks together, something along the lines of SX/B to enable a "BASIC" on the Propeller. So I don't believe we are way out of line in our thinking.
Unfortunately, due to personal circumstances (as I hinted at on IRC) I'm going to be short of time and resources for a couple of months (read as my compiling machine and related infrastructure is going to be packed in boxes somewhere on a ship in the Indian Ocean for a month or two), so while a bit of hacking and playing might be in order (time permitting), anything more serious may have to wait a couple of months.
As of about the 7th of Jan, my ability to get to the forums is going to be severely impacted for a month or so.. so while I'll check when I get the chance, reply time is going to be limited.
I am trying to get a bugfix of bst out before I get packed up, but I'm afraid it's likely to be just a bug fix.. the features I had planned might have to wait a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
A Shoe?!? Who throws a shoe? I mean really.....
Aside from the above quote, the local paper here held a poll.
Should he
A) Be sent to prison
C) Be lauded as a hero
D) Rewarded with a new pair of shoes.
... D got over 40% of the votes [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Here's a previous thread where I mentioned a native Prop compiler-compiler and the beginnings of a Basic compiler. I really have not worked on it much since this was posted other than to look at the possibility of compiling into Spin byte codes rather than LMM object code. The main issue is that it was written as a single program and it needs to be split into separate passes instead. To support that, I was trying to expand Rokicki's SD card routines to allow for multiple open files (and subdirectories). I ran into problems and just haven't been motivated to plow ahead. The dictionary works and variable allocation works. Some of the code generation works as well. I've now got a Demo Board set up with 512K bytes of EEPROM (4 x AT24C1024B) and I'll use that instead of the SD card to try to move ahead. The intention was to provide some kind of native program development platform other than FemtoBasic and Forth, preferably reasonably fast.
I wished C had the other 60. In all seriousness, that guy, shoe ducker, should be remembered like the austrian is, that will be fair.
Ken: At least your shoes are easier to use that your phone and computer, but don't tell the shoe manufacturer - you know what they did to Maxwell Smart's shoes!!
Now back to reality. It was only last night that I was chatting with baggers (I misunderstood a statement). I suggested that there is room in my ClusoInterpreter (not finally debugged because I got sidetracked - building a prop in a Spartan 3A FPGA) to possibly add LMM. Basically I have LMM (basic style) currently in my interpreter (as a zero footprint debugger). Anyway I said to baggers that we would need the compiler to be modified for this and there are two versions out there that the writers could modify.
One caveat - LMM variables have to be in hub unless the ClusoInterpreter is specifically compiled with overlays, or with features removed.
What do you all think?? Worth a new thread: "Embedded support for LMM in spin" ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]
This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.
I'm not going on the ship, just my furniture and infrastructure. I have the laptop and I can cross compile for all platforms from there, but I can't test anything other than Linux from the laptop until my Mac reaches dry land. I'll be working in the background, , but I have work lined up back in Aus that is going to keep me pegged until things settle down "Feb(ish)"
I like the idea of adding LMM support to the compiler. It has always been my aim once things got stable to add extra features like that, but then bst came along and sidetracked me. I think with the latest round of fixes the compiler is starting to stabilize and I have a versatile base from which to look at adding enhancements. I just need to sit down with someone and dedicate some time to understanding precisely what it is that you have in mind and how it needs to be put together, and I'm not going to have that time until I get Jan/Feb out the way and get settled back in a sane country. (Tax laws notwithstanding).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I'm writting a simple user interface, config panels, with 4 or 5 "controls". All drawing is made native in pasm, user inut and responses are done in LMM: relative jump, constant loading, subroutine call to LMM code, just 5 routines. It gets... complicated I mean there are loads of:
and other niceties (with the scheme I proposed some time ago). but, it works
The LMM (interpreter) that I implemented in the debugger uses 5 longs: 4 for the loop and execution and 1 for data. However, the actual LMM code is more complex because it has to take care of jumps.
A call to an LMM routine would make sense for the interpreter to implement. The completion of the LMM would then just be another fixed call to return to the interpreter. I could see this as being relatively easy to implement from both the interpreter and the compilers perspectives. The main complexity is the fact that mov instructions will not work as expected because variables are not in cog memory. This means it is not true LMM, but a variant or subset. However, I could see some real speed advantages of mixing spin and LMM.
Postedit:· New thread...
Embedded support for LMM within SPIN (discussion & proposals)·
http://forums.parallax.com/showthread.php?p=771505
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]
This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.
Post Edited (Cluso99) : 12/21/2008 10:31:03 AM GMT
I'd love to have a look at this Mike, but I can't find a link. Can you point me at the code so I have something to chew on over Christmas perhaps?
I was thinking originally about a BASIC compiler targeting SPIN bytecode but with a "helper cog" to provide some of the stuff the BASIC STAMP interpreter does, perhaps in LMM.
I'm not familiar with the STAMP at all. The Propeller is my first Parallax product, but I've read the BS2 manual and was thinking it might be fairly doable to provide a reasonable PBASIC style compiler (with assistance from a helper cog) to allow people an avenue to port their BS2 code directly to the Propeller (of course without the multi-tasking aspects that SPIN provides). Then I had a look at SX/B and thought that might be a nice idea also in LMM mode. Toys, lots of toys....
tpw_man and I were talking about building a BS2 emulator directly so people could use the BS2 tools and just "download" an image directly to the Propeller (Make the Prop look like a BS2), but he's been quiet of late and I've had a few other things on my plate (actually, to be honest I was all talk and he seemed keen to get into it).
I've been thinking harder about a SPIN compiler on the propeller. What I know about compilers can be written on the head of a pin. My first ever crack at it was bstc and I'm not incredibly proud of that code (it does seem to work though). I think with a bit more thought and a more educated approach, it might be possible to make it work on the propeller. It'd be as slow as a wet week in May, but it might just work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Remaining TODO Items :
- Clicky http:// links in source (Chuck Rice)
- Beep and triple flash for find/replace (Chuck Rice)
- Configurable colours (TChapman)
- Configurable keystrokes (Lots of people)
- Folding fix for blocks that have the BLOCK then a COMMENT in series. ie. PUB {{ (Chuck Rice)
- Block indicators (Practically everybody)
- Allow immediate compilation of a crash-recovered source file without saving first (Oldbitcollector)
Changelog in top post as usual.
OBC has been working overtime with this release feeding me great bug reports and I thank him for his patience with a crashing program. Linuxvolts was kind enough to E-mail me his code that was breaking things also. I can assure you all that any code you do send me remains completely confidential and I appreciate those that have taken the time to both report bugs and send me test cases to improve my code.
Now, I've made changes to the way ports are allocated after Ken Peterson spotted a bug on Windows (I assume it was windows as he mentioned COM4).
I may or may not have fixed this adequately. As a work-around you can always set the port manually in the ide prefs dialog, and I'd like to know if it's not fixed properly please.
If you do accidentally manage to set a port you did not want to, you can always default the auto-scan behaviour by using the IDE options and setting the port to "Auto".
At the suggestion of Ken, I've added "Project specific overrides". Each project file can be edited in the "Project Options" menu, which will allow you to specify project-specific search paths and compiler optimisation options. Please note that if you have *any* path in the project specific dialog, it disables and overrides the globally set search paths. To disable this, just remove all the paths in the project options.
The project additions have been "lightly tested". Please beat on them (Save first as if there _is_ a bug it's likely to be a crasher)
I've added options to set the tab width and disable smart tabs for Jay. I've left smart tabs functional for backspace and delete. Let's see how that behaves anyway before I make any major changes.
I think I've addressed all bugs and suggestions bar what is in the TODO above. Please keep shouting at me if I miss stuff and I'll get to it as soon as I can.
I have _not_ tested this anywhere as extensively as I usually do prior to a release. I'm sorry guys but I just don't have the horsepower right now. It has been lightly tested on Linux, OSX and the Win32 version under WINE.
Baring anything catastrophic over Christmas, this will likely be the last release until Feb. I have a one way ticket booked on the 4th of Feb, the development hardware and machines go into a box in the first week of Jan and I won't be able to really do much until mid Feb when they land (Unless I can con the SO to allow me to pack my Macs in the suitcase!)
Have a great Christmas everyone and a happy New Year!
(OOPS, forgot to mention the compiler is 10% faster again)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Post Edited (BradC) : 12/22/2008 4:18:03 PM GMT
Here's the thread (http://forums.parallax.com/showthread.php?p=714097) and I've reattached the archives for the start of the Basic compiler and the Meta2 Compiler-Compiler.
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Jay
Merry Xmas and Happy 2009
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
cruising][noparse][[/noparse]url=http://www.bluemagic.biz]cruising[noparse][[/noparse]/url][/url]
This is a [noparse][[/noparse]b]bold[noparse][[/noparse]/b] test.
Ok, I can see where I broke it but I can't fix it at the moment.
Workaround would be to use an older version of bst to set the path and then don't open that dialog again until I can get a fix out.
Sorry..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Thank you for the Christmas release!
It appears to address all the issues I've been working around. [noparse]:)[/noparse] Ya!
Will your hosting site stay online while you are moving?
Or do you want a mirror?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
The server I upload my stuff to is Co-Lo in the UK, so there is no chance of it going offline while I'm moving. Thanks for the offer though [noparse]:)[/noparse]
I've fixed both the bug Jay spotted, and also the problem with it auto-saving on close when not asked to. I'll try and get a new release built via my server at home in the next day or two, but with the Undersea cables cut my bandwidth is very limited and incredibly unreliable. They have said they'll get them fixed by the 27th of Dec though.
ssh sessions are painful when your ping times randomly alternate between 300m and 5000ms with a 50% packet loss.. [noparse]:([/noparse]
Have a Merry Christmas all [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
3 Bugs squashed, no features added. Lightly and quickly tested only.
Hope everyone had a great day yesterday!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
I thought there was an option to prevent BST from starting a new document upon start-up, but I can't find it. Am I imagining it?
There is no option to prevent that happening, however it's only supposed to happen when no other file is being opened on startup. So if you start bst by opening an associated file, or its doing a crash recovery, or you are opening with the "open last project" option then it should not create a blank page.
I'm sure I can add that as an option at some point though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
A straight day of coding and the editor is working perfectly. Looks like you've also addressed some of the timing issues at compile, as I'm seeing very few "lost propeller" during transmission issues.
Awesome Job!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Ok, I've tracked this down to a booboo in my Info.plist file. I've attached a replacement. Just pop it in bst.app/Contents to replace the existing Info.plist.
That should fix the file association problems for you. Please yell if it does something other than what it should. I've told it to make bst the default app for spin/eeprom/binary files. I'm not sure how tenacious that is but you *should* be able to change the association away from that if you need to.
In any case it shows you how green I really am at OSX development [noparse]:)[/noparse]
I've looked a bit closer at the problem where it always seems to open a new blank file on startup, but due to the way I've built things it's going to take me a little while to re-factor some code to fix it. I'll make sure it's in the next feature release anyway (I'm hoping not to have to make any bug-fixes between now and then, but you never know!)
@TChapman, I can't reproduce this here. Do you mean the program marker on the task bar in Windows? Are you using XP or Vista? I'll try to get it reproduced and fixed in any case.
When I get to Aus next week I'll have a couple of XP machines and a Vista machine to play with for a week or so, so I can give it a proper look over (I test inside a VirtualBox VM here)
sevs brought an interesting bug on windows to my attention on irc. Sometimes depending on windows version it's not properly picking up the proper location to store the recovery file and you get a message "Unable to save recovery to /.bst.recover". Are any other windows users seeing this issue? (Are there any other windows users?)
@Oldbitcollector, So glad it's working for you now. Interestingly enough I've not made _any_ changes at all to the propeller download code for about 3 releases now. I have some new bits planned to try and speed up the download, but they will have to wait until about mid - Feb I guess.
Happy new year all. I hope the financial crisis sees you all healthy and employed [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
And about preventing a blank file on open, it's not a huge deal, I'd prefer a blank editor, but I can always hit CMD-W at star-up.