No file required. Start BST. Type the following into the "Untitled1" TAB...
PUB start
#warn blabla
Hit F8.
Bang "Compiler Crashed"
BST 0.19.4-pre6
Compiler: 0.15.4-pre5
On: Debian unstable.
Of course you do have to have "Generate compiler "Warning" messages" switched on.
Wait up a minute ! After dicking around with that it started to compile with F8 with warning enabled or not.
Let's start again. Close BST, Open BST, type this program:
PUB start
#warn blabla
Hit F8, NOW IT COMPILES.
Check options, Warnings is "ON"
Hit F8 again, NOW IT CRASHES.
Seems a tad random. Have to dash now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Let's start again. Close BST, Open BST, type this program:
PUB start
#warn blabla
Hit F8, NOW IT COMPILES.
Check options, Warnings is "ON"
Hit F8 again, NOW IT CRASHES.
Seems a tad random. Have to dash now...
Yep, random.. or not.. I've quite obviously done something incredibly dumb when I *tried* to fix it last time. I can reproduce this reliably and I'll try and get a fix out asap (not going to be tonight though as I've had a lot of Scotch and experience has shown I tend to write odd code when I'm inebriated).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Sorry mate, forgot you had a hangover
If you can think at all today and while you are not too busy earning a living I was wondering if you could allow the terminal's hex window to dock with the parent. I'm lazy and it saves having to find both windows.
Peter Jakacki said...
HEY BRAD! YOU THERE!? HEY BRAD!
Sorry mate, forgot you had a hangover
Lucky for me I just don't get hangovers when I drink Scotch. No matter how much I imbibe.
Peter Jakacki said...
If you can think at all today and while you are not too busy earning a living I was wondering if you could allow the terminal's hex window to dock with the parent. I'm lazy and it saves having to find both windows.
Ugh, docking. Another one of those things that's completely different across all platforms. I'll certainly look at it, probably with a cocked head in a puppy "you want what?" style.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Let's start again. Close BST, Open BST, type this program:
PUB start
#warn blabla
Hit F8, NOW IT COMPILES.
Check options, Warnings is "ON"
Hit F8 again, NOW IT CRASHES.
Seems a tad random. Have to dash now...
Well, this turned out to be less of a bug in the code and more of a bug in my build environment. It was pulling old object files for the compiler from the bstc library directory rather than compiling them from the latest code. An obscure and hard to track down bug that simply went away when I did a "make clean" in the bstc directory.
I've redesigned my build environment so that can't happen again. 0.19.4-Pre7 is up and should be fixed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
You are "Cleaned" to nice in Yours build environment.
That BUG on meny "Help/About are BACK!.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Yes I use XP Sp3 Swedish edition with all uppdates.
And many Programs open at same time. I we see that some of them give me problems (mostly Old ones that we ben writen before XP else in begining of it's life)
BUT I need them in my other works and must live with theirs problems in runing.
Now it is only You latest uppdate that have that problem as one I reported to You before.
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Yes I use XP Sp3 Swedish edition with all uppdates.
And many Programs open at same time. I we see that some of them give me problems (mostly Old ones that we ben writen before XP else in begining of it's life)
BUT I need them in my other works and must live with theirs problems in runing.
Now it is only You latest uppdate that have that problem as one I reported to You before.
Christoffer J
Excellent. I have a Swedish copy of XP SP3 on the way to me now that I can install in a VM to see if I can reproduce this problem. I will get it fixed properly this time. Thanks for the report.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Well, I got hold of a copy of XP Home in Swedish (the Pro-SP3 is still coming) and as amusing as it was installing a localised operating system from motor memory (I can't read a word of it), even less amusing was the fact bst behaved perfectly. <grumble>.. have to wait for SP3 to turn up in another couple of hours and try again. When that fails, I'll have to figure out how to get a stack trace out of the windows version and send you a 30mb debug build with all symbols in it to try and see where it's crashing... [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.
It can be good with DEBUG version.
If You have aditional error tracing that can give You posibility to find problem.
Dont wory to send that - I will help as much it is posible.
That give me and others stable Tool - I have time to test's betwen my other work's (In time LAYOUTS to Propeller chip PCB's)
Some of them will be presented on forum in time we are clear with prototypes and all neesesary tests.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
pullmoll said...
I don't know if anyone already mentioned this: The listing output doesn't correctly expand tab characters (9). Instead of taking the current output offset into account, it seems to always emit 8 spaces. I know, it's just cosmetics, but should be relatively easy to fix!?
The listing emits the source as processed by the compiler, and the tab expansion into 8 spaces is how the Parallax Compiler appears to do it so bstc does it that way too.
Probably easy enough to fix in the compiler, but then it's possible to break compatibility in some very odd corner case. Don't really want to do that.
FWIW I gave homespun a try and it emits a listing where the tab characters are expanded correctly. I don't know if that has any implication on your fear of corner cases, however I'll now just use homespun if I intend to look at a listing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 11:32:11 AM GMT
FWIW I gave homespun a try and it emits a listing where the tab characters are expanded correctly. I don't know if that has any implication on your fear of corner cases, however I'll now just use homespun if I intend to look at a listing.
Yeah, I've been kinda experimenting with it a bit. There are 4,780 tab characters across 1,694 test files and they all seem to pass the regression test, so it's probably relatively safe. The only case I can think of that might not be safe is if someone (like me for example) uses TS=4 in vim and has a mix of tabs and whitespace. The tabs get expanded out to 8 and end up botching the indents.
I tend to get a bit uncomfortable when breaking fundamental compatibility with the Parallax Compiler though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Yeah, I've been kinda experimenting with it a bit. There are 4,780 tab characters across 1,694 test files and they all seem to pass the regression test, so it's probably relatively safe. The only case I can think of that might not be safe is if someone (like me for example) uses TS=4 in vim and has a mix of tabs and whitespace. The tabs get expanded out to 8 and end up botching the indents.
I tend to get a bit uncomfortable when breaking fundamental compatibility with the Parallax Compiler though.
I can understand that. I could as well change my editor's setup to emit blanks when I hit tab, it's just that I am so used to quickly going left through the tabs... I know, I should be using BST, but I only use BSTC and my beloved Makefile
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Can someone explain to me how to use diff to compare spin files?
Often I like to use diff -b to ignore changes in whitespace. This is clearly no good in a whitespace sensitive language.
If a file has been hacked with a mixture of spaces and tabs how on earth can we be sure what the indentation is supposed to be? And how do we avoid getting in a mess?
Is it so that tabs should be banned for spin files. Or mixtures of spaces and tabs should be banned?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
pullmoll said...
[noparse][[/noparse]
I can understand that. I could as well change my editor's setup to emit blanks when I hit tab, it's just that I am so used to quickly going left through the tabs... I know, I should be using BST, but I only use BSTC and my beloved Makefile
No, no, no... I'm a command line junkie. You can pry my GNU Makefiles and vim from my cold dead hands, that's why I wrote bstc the way I did. bst is a nice aside, but it's candy on top of the real tools. I like being able to go "bstc -f -p0 test.spin" and have it compile and load the prop *quickly*.
I have one more issue to kill with bstc before I get a new release out. I made some mods for Jazzed to the list file emission, and as part of that I had to change the way the parameters were parsed, but I broke it and I've not got around to fixing it yet (I might have to write my own command line parser to actually make it as flexible as I need).
I use bst a lot (it's why I wrote it), but I use bstc just as much for different stuff.
I am also very serious about Parallax compatibility. I have a regression test suite that compiles (currently) 1694 separate spin files and does a full binary compare against the Parallax compiler, so I *know* if you feed it the same text, you will get the same binary. I run this on all 4 platforms (OSX PPC & Intel are individual platforms as far as my build chain) before every release (I'm a lot more lax with the -pre's).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
heater said...
Is it so that tabs should be banned for spin files. Or mixtures of spaces and tabs should be banned?
Well, without wanting to start a flame war about how wide a TAB character is to be expanded, the classical meaning of it was to tabulate to the next position that is divisible by 8. This has been so for as long as I deal with computers, at least in every assembly language I've used. So if anything, the tabs should be expanded in the standard way and people who configured their editor to do something different with a TAB will face problems if they write Spin code with it.
If you wanted to ban tab characters in the source, that's not much of an issue, because I could just as well pre-process my source to do the tab expansion beforehand, while it would be a little awkward to do this Just kidding of course. You can hardly ban them if the Parallax compiler accepts them in a file that was edited with an external editor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
BradC said...
I am also very serious about Parallax compatibility. I have a regression test suite that compiles (currently) 1694 separate spin files and does a full binary compare against the Parallax compiler, so I *know* if you feed it the same text, you will get the same binary. I run this on all 4 platforms (OSX PPC & Intel are individual platforms as far as my build chain) before every release (I'm a lot more lax with the -pre's).
That is indeed serious, but as a lot of people depend on your code quite the right thing to do.
I think if the listing was going to expand tabs like most assemblers and compilers do it - with the exception of the Parallax compiler perhaps, I never used it - then if something goes wrong for the person who is using a mixture of tabs with width 4 and spaces can at least find the reason in the output.
The README accompanying BST(C) could perhaps give a hint not to do that, unless someone wanted to get in trouble sooner or later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
heater said...
Can someone explain to me how to use diff to compare spin files?
I just use diff [noparse]:)[/noparse] Of course all my files are written by me, on one particular operating system and I don't have to worry about other people bolloxing up my line endings and tab settings [noparse]:)[/noparse]
A lot of my source resides in subversion now, and it's pretty clever about handling diffs. The best part is if I accidentally screw up some whitespace, I can always generate a diff, edit it to take out the stuff I want to keep and then apply it with patch -R before I commit my changes. That way I keep the whitespace damage / noise to a minimum.
diff --strip-trailing-cr is a good way to be able to diff between *NIX/DOS line endings, but it does not account for whitespace damage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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, I have a "request", I know it's special because you don't get many of them, do you? Ok, this is more to do with how the compiler handles variables, normally the compiler will rearrange the variables in memory as longs,words,bytes just so the alignments don't get messed up. Well I just had a look at some code I was doing to optimize PASM accessing hub variables. Because RDBYTE or RDWORD takes just as long as a RDLONG I have been putting 2 words or 4 bytes into a long. It's much faster and determinate than multiple hub accesses as this is part of my UNICOM object I'm preparing.
The trouble is I have to refer to the variable as part of a long from Spin which makes it a little inefficient though acceptable but it's a pain referring to the offsets and having to remember what they are. There are two things that could make this better, one is to compile offsets such word[noparse][[/noparse]rx_hdtl+2] so that rx_hdtl+2 is precalculated with a global offset of the variable+2 rather than the offset of the variable and then adding 2 at run-time. The other way would be to allow pairs of words or quads of bytes to reside happily with their long cousins, perhaps a directive to override the rearranging. This is important for variables that are accessing by both Spin and PASM.
Of course I could just define them as words or bytes but I need them word aligned for PASM's RDLONG. Either way I am a bit cramped and dependent with the way the compiler works (gimme Forth any day ).
Peter Jakacki said...
There are two things that could make this better, one is to compile offsets such word[noparse][[/noparse]rx_hdtl+2] so that rx_hdtl+2 is precalculated with a global offset of the variable+2 rather than the offset of the variable and then adding 2 at run-time.
Funnily enough, I was thinking about just this in the shower this morning but for different reasons.
In another thread the whole fred[noparse][[/noparse]0] vs fred came up, and I thought it would be possible to have the compiler notice the index is a constant and just generate the simplest absolute code to access it. I'd not thought about the byte/word/long case though.
In your example above, if rx_hdtl is a constant and the compiler has constant folding enabled then it will calculate it up for you anyway, but it still generates an indexed address function where it could generate an absolute address read.
The biggest issue comes about when you have multiple instances of an object. You still need to use @ to get the proper offset of anything in a VAR section, but I think I could have the compiler simplify it significantly for anything in a DAT section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Peter Jakacki said...
There are two things that could make this better, one is to compile offsets such word[noparse][[/noparse]rx_hdtl+2] so that rx_hdtl+2 is precalculated with a global offset of the variable+2 rather than the offset of the variable and then adding 2 at run-time.
Funnily enough, I was thinking about just this in the shower this morning but for different reasons.
<snip>
So if you came up with that in the shower then where were you when you came up with B S T ?????
Anyway, specifying [noparse][[/noparse] variable+offset ] rather than [noparse][[/noparse] variable ] [noparse][[/noparse] offset ] is just a way of trying to get it precompiled as a constant. So I could live with the way it is for now but how about the whole long/word/byte thing in memory so that I can mix in 2 words as a long etc.
So if you came up with that in the shower then where were you when you came up with B S T ?????
Probably the shower. I seem to do my best thinking there, much to the detriment of my water and gas bill..
Peter Jakacki said...
Anyway, specifying [noparse][[/noparse] variable+offset ] rather than [noparse][[/noparse] variable ] [noparse][[/noparse] offset ] is just a way of trying to get it precompiled as a constant. So I could live with the way it is for now but how about the whole long/word/byte thing in memory so that I can mix in 2 words as a long etc.
I'm not *quite* sure I have a handle on this..
So let's say we define a long, and we'll call it X.
Are you saying you'd like to be able to alias the words and bytes to variables that just access the relevant parts of the allocated long (a bit like a structure)?
The issue with not reordering variables is you need to guarantee somehow that all the alignment is correct. Re-ordering is just the easiest way (and most compact) to ensure that occurs.
I guess there could be a keyword that prevents the compiler re-ordering the variables, but then you need warnings or errors when you have a variable that is not correctly aligned and it gets messy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Ok, maybe you could take another shower and figure out a nice simple way to do this or maybe you could just have a button labeled "are you feeling lucky punk". I mean, if I press the button I accept the consequences the same way as if I write a totally dumb program even though it may be lint free. The compiler can't control everything the programmer writes and the programmer can't control everything the EU does with it either. All you can hope to do is make it so it doesn't break under normal circumstances, warn if it detects anything that doesn't seem right, and the rest is not your responsibility, the world will still keep turning. Well, there are some programmers who would try to make it your responsibility "the compiler should have warned me" but we won't go there.
So I'm not really worried about the fast indexing thing but if I could just put mixed variables in the order that I want them in and possibly even specify an origin with the compiler not trying to second guess everything. Wouldn't an odd offset for a variable be an easy way to warn about alignment problems? For instance you would expect the last two bits of a long address to be ...xx00.
So I'm not really worried about the fast indexing thing but if I could just put mixed variables in the order that I want them in and possibly even specify an origin with the compiler not trying to second guess everything. Wouldn't an odd offset for a variable be an easy way to warn about alignment problems? For instance you would expect the last two bits of a long address to be ...xx00.
Yep, I think I can do it on a per-file basis. Use a defined identifier of some kind in any of the VAR blocks in that file and it would disable the re-ordering of variables. It should also stop with an error if it detects an alignment it doesn't like *or* automatically pad to suit the desired alignment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Cars can be driven on the footpath/sidewalk though they shouldn't be but imagine if the on-board computer said "no you can't", or speeding down the highway and you needed to slow the car down and it said "no you can't". Manual override is always the user's responsibility and there aren't many occasions where it's needed but when you need it you need it, so let it go through as is, it won't kill the compiler, will it? Maybe you could write the compiler with a sense of humor so that when the program is edited later on to comply the compiler can do a pop-up saying "I told you so, you wouldn't listen, ...titch titch titch.....nag nag nag".
*DO NOT USE THIS UNLESS YOU WANT TO FLIRT WITH BROKEN CODE*
This code is pretty likely to munge your project files if you save a project with it. Be warned!! (I'm half way through a re-factor but I wanted to get this out for Peter to test).
This code has 2 more or less significant changes.
A ) It *should* parse tabs properly in the source and translate that to the list file.
B ) If you define your variables with a VARX block instead of a VAR block, the compiler will NOT reorder them for you. It will (expletive) and moan if you try and allocate variables that are not aligned. It will however create them in any order you define them. This is practically completely untested except to compile some spin files and look at the output. I have no idea right now if the generated code will even work. It should, but you never know.
You *MUST* either define all blocks in a source file (object) as VAR or VARX. If you try to mix them, it will simply use the definition of the last block to do the compilation.
I repeat *THIS CODE WILL MUNGE YOUR PROJECT FILES!!!!!!*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Comments
Hit F8.
Bang "Compiler Crashed"
BST 0.19.4-pre6
Compiler: 0.15.4-pre5
On: Debian unstable.
Of course you do have to have "Generate compiler "Warning" messages" switched on.
Wait up a minute ! After dicking around with that it started to compile with F8 with warning enabled or not.
Let's start again. Close BST, Open BST, type this program:
PUB start
#warn blabla
Hit F8, NOW IT COMPILES.
Check options, Warnings is "ON"
Hit F8 again, NOW IT CRASHES.
Seems a tad random. Have to dash now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yep, random.. or not.. I've quite obviously done something incredibly dumb when I *tried* to fix it last time. I can reproduce this reliably and I'll try and get a fix out asap (not going to be tonight though as I've had a lot of Scotch and experience has shown I tend to write odd code when I'm inebriated).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Sorry mate, forgot you had a hangover
If you can think at all today and while you are not too busy earning a living I was wondering if you could allow the terminal's hex window to dock with the parent. I'm lazy and it saves having to find both windows.
Thanks mate!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Lucky for me I just don't get hangovers when I drink Scotch. No matter how much I imbibe.
Ugh, docking. Another one of those things that's completely different across all platforms. I'll certainly look at it, probably with a cocked head in a puppy "you want what?" style.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Well, this turned out to be less of a bug in the code and more of a bug in my build environment. It was pulling old object files for the compiler from the bstc library directory rather than compiling them from the latest code. An obscure and hard to track down bug that simply went away when I did a "make clean" in the bstc directory.
I've redesigned my build environment so that can't happen again. 0.19.4-Pre7 is up and should be fixed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You are "Cleaned" to nice in Yours build environment.
That BUG on meny "Help/About are BACK!.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Boooo! Hiss!
Are you using Windows XP Swedish edition?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Yes I use XP Sp3 Swedish edition with all uppdates.
And many Programs open at same time. I we see that some of them give me problems (mostly Old ones that we ben writen before XP else in begining of it's life)
BUT I need them in my other works and must live with theirs problems in runing.
Now it is only You latest uppdate that have that problem as one I reported to You before.
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Excellent. I have a Swedish copy of XP SP3 on the way to me now that I can install in a VM to see if I can reproduce this problem. I will get it fixed properly this time. Thanks for the report.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
It can be good with DEBUG version.
If You have aditional error tracing that can give You posibility to find problem.
Dont wory to send that - I will help as much it is posible.
That give me and others stable Tool - I have time to test's betwen my other work's (In time LAYOUTS to Propeller chip PCB's)
Some of them will be presented on forum in time we are clear with prototypes and all neesesary tests.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
FWIW I gave homespun a try and it emits a listing where the tab characters are expanded correctly. I don't know if that has any implication on your fear of corner cases, however I'll now just use homespun if I intend to look at a listing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 11:32:11 AM GMT
Yeah, I've been kinda experimenting with it a bit. There are 4,780 tab characters across 1,694 test files and they all seem to pass the regression test, so it's probably relatively safe. The only case I can think of that might not be safe is if someone (like me for example) uses TS=4 in vim and has a mix of tabs and whitespace. The tabs get expanded out to 8 and end up botching the indents.
I tend to get a bit uncomfortable when breaking fundamental compatibility with the Parallax Compiler though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I can understand that. I could as well change my editor's setup to emit blanks when I hit tab, it's just that I am so used to quickly going left through the tabs... I know, I should be using BST, but I only use BSTC and my beloved Makefile
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Often I like to use diff -b to ignore changes in whitespace. This is clearly no good in a whitespace sensitive language.
If a file has been hacked with a mixture of spaces and tabs how on earth can we be sure what the indentation is supposed to be? And how do we avoid getting in a mess?
Is it so that tabs should be banned for spin files. Or mixtures of spaces and tabs should be banned?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, no, no... I'm a command line junkie. You can pry my GNU Makefiles and vim from my cold dead hands, that's why I wrote bstc the way I did. bst is a nice aside, but it's candy on top of the real tools. I like being able to go "bstc -f -p0 test.spin" and have it compile and load the prop *quickly*.
I have one more issue to kill with bstc before I get a new release out. I made some mods for Jazzed to the list file emission, and as part of that I had to change the way the parameters were parsed, but I broke it and I've not got around to fixing it yet (I might have to write my own command line parser to actually make it as flexible as I need).
I use bst a lot (it's why I wrote it), but I use bstc just as much for different stuff.
I am also very serious about Parallax compatibility. I have a regression test suite that compiles (currently) 1694 separate spin files and does a full binary compare against the Parallax compiler, so I *know* if you feed it the same text, you will get the same binary. I run this on all 4 platforms (OSX PPC & Intel are individual platforms as far as my build chain) before every release (I'm a lot more lax with the -pre's).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Well, without wanting to start a flame war about how wide a TAB character is to be expanded, the classical meaning of it was to tabulate to the next position that is divisible by 8. This has been so for as long as I deal with computers, at least in every assembly language I've used. So if anything, the tabs should be expanded in the standard way and people who configured their editor to do something different with a TAB will face problems if they write Spin code with it.
If you wanted to ban tab characters in the source, that's not much of an issue, because I could just as well pre-process my source to do the tab expansion beforehand, while it would be a little awkward to do this
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/15/2010 2:31:32 PM GMT
That is indeed serious, but as a lot of people depend on your code quite the right thing to do.
I think if the listing was going to expand tabs like most assemblers and compilers do it - with the exception of the Parallax compiler perhaps, I never used it - then if something goes wrong for the person who is using a mixture of tabs with width 4 and spaces can at least find the reason in the output.
The README accompanying BST(C) could perhaps give a hint not to do that, unless someone wanted to get in trouble sooner or later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I just use diff [noparse]:)[/noparse] Of course all my files are written by me, on one particular operating system and I don't have to worry about other people bolloxing up my line endings and tab settings [noparse]:)[/noparse]
A lot of my source resides in subversion now, and it's pretty clever about handling diffs. The best part is if I accidentally screw up some whitespace, I can always generate a diff, edit it to take out the stuff I want to keep and then apply it with patch -R before I commit my changes. That way I keep the whitespace damage / noise to a minimum.
diff --strip-trailing-cr is a good way to be able to diff between *NIX/DOS line endings, but it does not account for whitespace damage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
The trouble is I have to refer to the variable as part of a long from Spin which makes it a little inefficient though acceptable but it's a pain referring to the offsets and having to remember what they are. There are two things that could make this better, one is to compile offsets such word[noparse][[/noparse]rx_hdtl+2] so that rx_hdtl+2 is precalculated with a global offset of the variable+2 rather than the offset of the variable and then adding 2 at run-time. The other way would be to allow pairs of words or quads of bytes to reside happily with their long cousins, perhaps a directive to override the rearranging. This is important for variables that are accessing by both Spin and PASM.
Of course I could just define them as words or bytes but I need them word aligned for PASM's RDLONG. Either way I am a bit cramped and dependent with the way the compiler works (gimme Forth any day
Any ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Funnily enough, I was thinking about just this in the shower this morning but for different reasons.
In another thread the whole fred[noparse][[/noparse]0] vs fred came up, and I thought it would be possible to have the compiler notice the index is a constant and just generate the simplest absolute code to access it. I'd not thought about the byte/word/long case though.
In your example above, if rx_hdtl is a constant and the compiler has constant folding enabled then it will calculate it up for you anyway, but it still generates an indexed address function where it could generate an absolute address read.
The biggest issue comes about when you have multiple instances of an object. You still need to use @ to get the proper offset of anything in a VAR section, but I think I could have the compiler simplify it significantly for anything in a DAT section.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
So if you came up with that in the shower then where were you when you came up with B S T ?????
Anyway, specifying [noparse][[/noparse] variable+offset ] rather than [noparse][[/noparse] variable ] [noparse][[/noparse] offset ] is just a way of trying to get it precompiled as a constant. So I could live with the way it is for now but how about the whole long/word/byte thing in memory so that I can mix in 2 words as a long etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Probably the shower. I seem to do my best thinking there, much to the detriment of my water and gas bill..
I'm not *quite* sure I have a handle on this..
So let's say we define a long, and we'll call it X.
We have
Are you saying you'd like to be able to alias the words and bytes to variables that just access the relevant parts of the allocated long (a bit like a structure)?
The issue with not reordering variables is you need to guarantee somehow that all the alignment is correct. Re-ordering is just the easiest way (and most compact) to ensure that occurs.
I guess there could be a keyword that prevents the compiler re-ordering the variables, but then you need warnings or errors when you have a variable that is not correctly aligned and it gets messy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
So I'm not really worried about the fast indexing thing but if I could just put mixed variables in the order that I want them in and possibly even specify an origin with the compiler not trying to second guess everything. Wouldn't an odd offset for a variable be an easy way to warn about alignment problems? For instance you would expect the last two bits of a long address to be ...xx00.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Yep, I think I can do it on a per-file basis. Use a defined identifier of some kind in any of the VAR blocks in that file and it would disable the re-ordering of variables. It should also stop with an error if it detects an alignment it doesn't like *or* automatically pad to suit the desired alignment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
*DO NOT USE THIS UNLESS YOU WANT TO FLIRT WITH BROKEN CODE*
This code is pretty likely to munge your project files if you save a project with it. Be warned!! (I'm half way through a re-factor but I wanted to get this out for Peter to test).
This code has 2 more or less significant changes.
A ) It *should* parse tabs properly in the source and translate that to the list file.
B ) If you define your variables with a VARX block instead of a VAR block, the compiler will NOT reorder them for you. It will (expletive) and moan if you try and allocate variables that are not aligned. It will however create them in any order you define them. This is practically completely untested except to compile some spin files and look at the output. I have no idea right now if the generated code will even work. It should, but you never know.
You *MUST* either define all blocks in a source file (object) as VAR or VARX. If you try to mix them, it will simply use the definition of the last block to do the compilation.
I repeat *THIS CODE WILL MUNGE YOUR PROJECT FILES!!!!!!*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.
Your Download page have problems
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