Ok, that is super peculiar, however it explains the odd bug you had where the "Share and Enjoy" popped up.
Let me look at the 0.17 code a bit closer and see if there is anything I can see that would cause that to happen on OSX....
This is rapidly becoming a *very* peculiar bug.... I dunno whether to smile, cry or scream!
<edit>
There have been a number of bug fixes to the underlying tab component and Carbon widget set I'm using since 0.17 was released.
Would you mind terribly if I asked you to try upgrading to 0.18-pre5 to see if the problem has gone away?
I've also made some fixes to the editor component handling code since 0.17, but it had been like that since the very first release, so I don't think that is the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Brad,
I've grabbed the latest BST.exe.zip and have tried to compile the latest Zicog, but it just shows a popup box ( compile box ) showing zicog_demo and one blue square
then waits for AGES ( with only one blue box ) then the popup box disappears if i swap windows.
any ideas?
Baggers said...
Brad,
I've grabbed the latest BST.exe.zip and have tried to compile the latest Zicog, but it just shows a popup box ( compile box ) showing zicog_demo and one blue square
then waits for AGES ( with only one blue box ) then the popup box disappears if i swap windows.
any ideas?
PS, I'm running Vista Business SP1 ( 32bit )
also, it works fine with compiling other files.
Not really.. I'll see what I can do about testing on Windows.. none of the -pre builds have been tested on Win32 at all I'm afraid..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Double curses..
I have Vista Ultimate SP1 in a 32 bit VM here and it behaves itself _perfectly_....
Attached is _exactly_ the binary I just tested with, compiled about 5 minutes ago from my latest code base...
Give that a whirl and see what happens.
I did a clean install, mapped the zicog directory, selected the extensions enabled in compiler options, opened zicog_demo.spin and pushed F8...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
A) are you dual/multi core? My test setup is single core and the compiler is threaded.
could you possibly download bstc.exe and compile it from the command line to see if the compiler is spitting out something it should not?
The background to that is the IO library I'm using can't cope with console output in a multi-threaded environment on Windows.. it just locks up, and I wonder if there is something it's trying to tell us that's killing it.
You should be able to compile it with
bstc.exe -Ox -w2 zicog_demo.exe
It's behaving here, but then I have a completely different configuration..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Brad, it's a Intel(R) Core(TM)2 Duo CPU T7250@2Ghz
if that's any help
I have the the latest bstc ( downloaded last night ), but apparently x is an invalid optimiser flag [noparse]:D[/noparse]
removing the -Ox· oh, and using zicog_demo.spin not exe ;D
gives
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 22:54:28 on 2009/02/23
Loading Object zicog_demo
An unhandled exception occurred at $00414E9A :
EAccessViolation : Access violation · $00414E9A · $00430ACC · $004117E7 · $00411E34 · $004129B5 · $00402772
oh, and by the way, it restored an old file saying it had crashed, but it restored a very old file over my current working [noparse]:([/noparse] MEGA MEGA Doh!
Baggers said...
Brad, it's a Intel(R) Core(TM)2 Duo CPU T7250@2Ghz
if that's any help
I have the the latest bstc ( downloaded last night ), but apparently x is an invalid optimiser flag [noparse]:D[/noparse]
removing the -Ox oh, and using zicog_demo.spin not exe ;D
gives
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 22:54:28 on 2009/02/23
Oh.. that's not the latest compiler.. that's the latest *release* compiler.. that one *will* crash with anything # in it...
the latest beta code can be found here.. www.fnarfbargle.com/bst/snapshots
Baggers said...
oh, and by the way, it restored an old file saying it had crashed, but it restored a very old file over my current working [noparse]:([/noparse] MEGA MEGA Doh!
That *is* peculiar.. while it will auto-recover a file that auto-recovery saved at compile time, it will not replace anything with it. It simply opens it as an unsaved file in the editor..
If it overwrote something by itself then I have a _grave_ bug I need to fix!
heater said...
I can't compile zicog_demo in Windows XP either. Running in VirtalBox under Debian.
Just downloaded the build the post above.
It trips up at #ifdef TriBladeProp with
"Expected Object Definition"
I do have Non-Parallax Compatible Extentions enabled.
Hrm.. I tried the .exe I posted recently in Vista (in a VM) and under WINE and it compiled zicog-0.9 perfectly with both of them... something is _very_ wrong with this picture..
If you are enabling Non-Parallax extensions in the project file rather than the compiler options dialog, are you remembering to check "Override global compiler optimisations" in the project dialog?
I just can't think of anything else that would cause this to work for me and not you...
I have bst.exe in WINE open in front of me and it's compiling every time.. <sob sob sob>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I get a "data after RES" message when a table of data follows a group of RES statements. I tried putting a DAT between the RES and the LONGs of the table, but still get the warning message. The table is the font table at the end of Chip's high resolution text vga driver (obex.parallax.com/objects/69/).
Mike Green said...
Small bug in pre5 MacOS version:
I get a "data after RES" message when a table of data follows a group of RES statements. I tried putting a DAT between the RES and the LONGs of the table, but still get the warning message. The table is the font table at the end of Chip's high resolution text vga driver (obex.parallax.com/objects/69/).
Yep.. It's not actually a bug as such.. I intended it to work that way.
I could not come up with a really good heuristic to determine when data after res is a genuine mistake and when it's likely to be desired, so I just left it to warn on any data after res.
I'm not sure really how to go about properly detecting it. A bit like a jmp without # will always warn, whether you want it or not.. but I'm very open to suggestions.
Separating them with another DAT statement might be one way to do it, but that would require some serious re-factoring of my code as I separate all the blocks out into individual types during the tokenisation stage, so to the compiler it only sees one big DAT block..
@Baggers. I'm completely out of ideas now.. I might have to sleep on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Baggers, it occurs to me to ask if you made _any_ changes (source/define/breathed on it) at all to heater's zicog 0.9 zip file prior to attempting to compile it?
I can see several spots in the compiler where I'm outputting to the console, but they all occur only in cases of "I've fallen and I can't get up" just prior to the "Earth shattering Kaboom".(Severe unrecoverable compiler internal error - I've only seen these myself very rarely when testing new and potentially braindamaged compiler code)
I'm not convinced right now that it is a threading related bug, but I'm at a complete dead loss otherwise. I just can _not_ reproduce this here (I even tried it on a brand spanking new dual core intel machine with Vista home premium (or something like that..)
I'm also at a loss as to why the -pre5 version is hanging on startup for you.. I'm investigating but working with windows does tend to get my blood pressure up a bit..
At this point I'd normally say "Send me a copy of your .bst.ini file" but in the windows version I put it in the registry. If you are familiar with regedit you could export the contents of HKCU\software\camsoft\bst\0.1 and email or pm me. Maybe there is something sinister hiding in there that is blowing things up on startup.
When it hangs at the splash screen, is it idle or chewing 100% of a core?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
One small thing I would like to see in the directory tree window is a 'refresh' facility. If you save a project/file and create a new folder within the save dialog window, the new folder doesn't show up in the tree until you restart bst.
A split pane view in the editor window would be awesome too, so you could edit/view two spin files side-by-side.
I have just found a few mins to play with compiling ZiCog v0.9 with that same BST download above on my Windows XP in a VirtualBox on Debian. Still no joy.
I've tried all kind of ways of putting defines in the project or compiler preferences and playing with Non-Parallax extensions in the project and compiler options dialog, and checking "Override global compiler optimisations"
My defines were never recognized. On many occasions the defines disappeared from one or both dialogs. On a few occasions I got a crash "Cannot assign Nil to TTextString".
I'll have to get some sleep and try to find some reproducible steps in the morning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK not sleeping yet. This gets weirder. I just thought to delete any project files hanging around. Trouble is I could not delete one of them zicog.sprj. Windows refused saying "Error Deleting file or Folder" "Cannot delete file 'Cannot read from the source disk or file"
So, I copy the entire directory, to find it has no zicog.sprj in it and delete the original directory. OK it's gone.
Now open zicog_demo.spin. Set my defines in the compiler options and check "Non Parallax compatible ...". Never touch any Project stuff. Won't compile. Check the compiler setings, defines are still there "Non Paralla..." still there. Still wont compile.
Now uncomment "#define CPU_8080" and "#define PropDemoBoard" in zicog_demo.spin. It now compiles. Hurrah!
So some how those compiler defines are never seen.
Continuing: Set the same defines in the project dialog along with non-compat and override.
Close the project dialog and try to open it again. Bam! There is that TTextString error.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
FrameShift. said...
I also get the popup showing zicog_demo when compiling.. doesn't seem to do anything..
tried with v0.17 with no code changes.
Running dual core with XP Pro. Same result with linux.
Yes, it will. 0.17 had a bug where any form of #define would crash the compiler and the main application would fail to know the compiler was crashed.
You *must* use at least 0.18-pre5 to be able to use any #defines or conditionals of any kind.
I'm going out now.. when I get home this afternoon I'll publish a -pre6 from my current code base and try figuring out what is broken on Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
heater said...
I have just found a few mins to play with compiling ZiCog v0.9 with that same BST download above on my Windows XP in a VirtualBox on Debian. Still no joy.
I've tried all kind of ways of putting defines in the project or compiler preferences and playing with Non-Parallax extensions in the project and compiler options dialog, and checking "Override global compiler optimisations"
My defines were never recognized. On many occasions the defines disappeared from one or both dialogs. On a few occasions I got a crash "Cannot assign Nil to TTextString".
Oh.. something completely *non obvious* here. Anything you define in the project options dialog must be without the "#".. so in the code you use
#define gronk
.. while in the project defines you just use
gronk
... Sorry, I really should have mentioned that.. just the same as with bstc you'd use
bstc -Ox -D gronk test.spin
.. for those following along at home... the current -pre4 of bstc does not support -D yet.. the next pre-release will.. heater has some test code..
BIG FLASHY MESSAGE HERE <----
Also, the defines tab showing up in the bst compiler options is a BUG! There is no defines tab there and any define you put in there will do _nothing_. Not get saved and just disappear when you close the dialog.
Defines are only used/recorded in the project options/file.
Told you it was *raw* and mostly untested code! [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Baggers, I still don't know what was causing your lockup on Win32.. but I have an idea it was related to recovery files and old versions of the compiler. I've also found a condition that could cause it to restore a very old recovery file that was hanging around by mistake. Let me walk through it..
load bst, create/modify a file and compile (without saving it first!). A recovery file is created as there is a modified tab in the ide.
Now.. let's edit the files some more (a lot) but save them to disk prior to every compile.. the recovery file remains on disk and is never updated.
Now crash the ide.. when you re-start, the out-of-date recovery file is restored and loads into the ide as unsaved data.
I can't find any way for that file to overwrite the updated source file on disk unless you manually save it, but stranger things have happened!
In any case, I've squashed that particular bug and we now take care to properly clean up recovery files if there is no need to save one (all tabs are unmodified on compile).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Baggers said...
That fix works, it loads now. [noparse]:)[/noparse]
I get a compile error too now ( on #else in zicog_demo.spin ) rather than a lock up [noparse]:)[/noparse]
Go to Tools->Compiler Preferences->Optimisations and check "Non-Parallax Compatible Extensions".
If it does not compile after than then I'll be out behind the woolshed with a shotgun....
Baggers said...
with the restore file, can't you overwrite the restore file just before compile? and delete it after a restore [noparse]:)[/noparse]
Yes.. that is what was happening.. except when *all* tabs were unmodified the routine bailed early without writing, deleting or over-writing anything..
In that case, it now checks for a restore file and removes it if there is nothing to save. Job done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Comments
Let me look at the 0.17 code a bit closer and see if there is anything I can see that would cause that to happen on OSX....
This is rapidly becoming a *very* peculiar bug.... I dunno whether to smile, cry or scream!
<edit>
There have been a number of bug fixes to the underlying tab component and Carbon widget set I'm using since 0.17 was released.
Would you mind terribly if I asked you to try upgrading to 0.18-pre5 to see if the problem has gone away?
I've also made some fixes to the editor component handling code since 0.17, but it had been like that since the very first release, so I don't think that is the problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Post Edited (BradC) : 5/5/2009 7:59:08 AM GMT
I've grabbed the latest BST.exe.zip and have tried to compile the latest Zicog, but it just shows a popup box ( compile box ) showing zicog_demo and one blue square
then waits for AGES ( with only one blue box ) then the popup box disappears if i swap windows.
any ideas?
PS, I'm running Vista Business SP1 ( 32bit )
also, it works fine with compiling other files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Not really.. I'll see what I can do about testing on Windows.. none of the -pre builds have been tested on Win32 at all I'm afraid..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I have Vista Ultimate SP1 in a 32 bit VM here and it behaves itself _perfectly_....
Attached is _exactly_ the binary I just tested with, compiled about 5 minutes ago from my latest code base...
Give that a whirl and see what happens.
I did a clean install, mapped the zicog directory, selected the extensions enabled in compiler options, opened zicog_demo.spin and pushed F8...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
A) are you dual/multi core? My test setup is single core and the compiler is threaded.
The background to that is the IO library I'm using can't cope with console output in a multi-threaded environment on Windows.. it just locks up, and I wonder if there is something it's trying to tell us that's killing it.
You should be able to compile it with
bstc.exe -Ox -w2 zicog_demo.exe
It's behaving here, but then I have a completely different configuration..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
if that's any help
I have the the latest bstc ( downloaded last night ), but apparently x is an invalid optimiser flag [noparse]:D[/noparse]
removing the -Ox· oh, and using zicog_demo.spin not exe ;D
gives
Brads Spin Tool Compiler v0.14 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 22:54:28 on 2009/02/23
Loading Object zicog_demo
An unhandled exception occurred at $00414E9A :
EAccessViolation : Access violation
· $00414E9A
· $00430ACC
· $004117E7
· $00411E34
· $004129B5
· $00402772
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Just downloaded the build the post above.
It trips up at #ifdef TriBladeProp with
"Expected Object Definition"
I do have Non-Parallax Compatible Extentions enabled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 5/6/2009 10:49:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oh.. that's not the latest compiler.. that's the latest *release* compiler.. that one *will* crash with anything # in it...
the latest beta code can be found here..
www.fnarfbargle.com/bst/snapshots
That *is* peculiar.. while it will auto-recover a file that auto-recovery saved at compile time, it will not replace anything with it. It simply opens it as an unsaved file in the editor..
If it overwrote something by itself then I have a _grave_ bug I need to fix!
Hrm.. I tried the .exe I posted recently in Vista (in a VM) and under WINE and it compiled zicog-0.9 perfectly with both of them... something is _very_ wrong with this picture..
If you are enabling Non-Parallax extensions in the project file rather than the compiler options dialog, are you remembering to check "Override global compiler optimisations" in the project dialog?
I just can't think of anything else that would cause this to work for me and not you...
I have bst.exe in WINE open in front of me and it's compiling every time.. <sob sob sob>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I get a "data after RES" message when a table of data follows a group of RES statements. I tried putting a DAT between the RES and the LONGs of the table, but still get the warning message. The table is the font table at the end of Chip's high resolution text vga driver (obex.parallax.com/objects/69/).
still waiting for it to open [noparse]:([/noparse]
bst loading.... please wait....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Yep.. It's not actually a bug as such.. I intended it to work that way.
I could not come up with a really good heuristic to determine when data after res is a genuine mistake and when it's likely to be desired, so I just left it to warn on any data after res.
I'm not sure really how to go about properly detecting it. A bit like a jmp without # will always warn, whether you want it or not.. but I'm very open to suggestions.
Separating them with another DAT statement might be one way to do it, but that would require some serious re-factoring of my code as I separate all the blocks out into individual types during the tokenisation stage, so to the compiler it only sees one big DAT block..
@Baggers. I'm completely out of ideas now.. I might have to sleep on it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I can see several spots in the compiler where I'm outputting to the console, but they all occur only in cases of "I've fallen and I can't get up" just prior to the "Earth shattering Kaboom".(Severe unrecoverable compiler internal error - I've only seen these myself very rarely when testing new and potentially braindamaged compiler code)
I'm not convinced right now that it is a threading related bug, but I'm at a complete dead loss otherwise. I just can _not_ reproduce this here (I even tried it on a brand spanking new dual core intel machine with Vista home premium (or something like that..)
I'm also at a loss as to why the -pre5 version is hanging on startup for you.. I'm investigating but working with windows does tend to get my blood pressure up a bit..
At this point I'd normally say "Send me a copy of your .bst.ini file" but in the windows version I put it in the registry. If you are familiar with regedit you could export the contents of HKCU\software\camsoft\bst\0.1 and email or pm me. Maybe there is something sinister hiding in there that is blowing things up on startup.
When it hangs at the splash screen, is it idle or chewing 100% of a core?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
as for -pre5 it was idle.
I've also pm'd the reg [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
A split pane view in the editor window would be awesome too, so you could edit/view two spin files side-by-side.
Thanks for a great product!
Russ.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I've tried all kind of ways of putting defines in the project or compiler preferences and playing with Non-Parallax extensions in the project and compiler options dialog, and checking "Override global compiler optimisations"
My defines were never recognized. On many occasions the defines disappeared from one or both dialogs. On a few occasions I got a crash "Cannot assign Nil to TTextString".
I'll have to get some sleep and try to find some reproducible steps in the morning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So, I copy the entire directory, to find it has no zicog.sprj in it and delete the original directory. OK it's gone.
Now open zicog_demo.spin. Set my defines in the compiler options and check "Non Parallax compatible ...". Never touch any Project stuff. Won't compile. Check the compiler setings, defines are still there "Non Paralla..." still there. Still wont compile.
Now uncomment "#define CPU_8080" and "#define PropDemoBoard" in zicog_demo.spin. It now compiles. Hurrah!
So some how those compiler defines are never seen.
Continuing: Set the same defines in the project dialog along with non-compat and override.
Close the project dialog and try to open it again. Bam! There is that TTextString error.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, it will. 0.17 had a bug where any form of #define would crash the compiler and the main application would fail to know the compiler was crashed.
You *must* use at least 0.18-pre5 to be able to use any #defines or conditionals of any kind.
I'm going out now.. when I get home this afternoon I'll publish a -pre6 from my current code base and try figuring out what is broken on Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
-Tom
Post Edited (FrameShift.) : 5/6/2009 11:24:05 PM GMT
Oh.. something completely *non obvious* here. Anything you define in the project options dialog must be without the "#".. so in the code you use
#define gronk
.. while in the project defines you just use
gronk
... Sorry, I really should have mentioned that.. just the same as with bstc you'd use
bstc -Ox -D gronk test.spin
.. for those following along at home... the current -pre4 of bstc does not support -D yet.. the next pre-release will.. heater has some test code..
BIG FLASHY MESSAGE HERE <----
Also, the defines tab showing up in the bst compiler options is a BUG! There is no defines tab there and any define you put in there will do _nothing_. Not get saved and just disappear when you close the dialog.
Defines are only used/recorded in the project options/file.
Told you it was *raw* and mostly untested code! [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Post Edited (BradC) : 5/7/2009 5:49:28 AM GMT
www.fnarfbargle.com/bst/snapshots
Baggers, I still don't know what was causing your lockup on Win32.. but I have an idea it was related to recovery files and old versions of the compiler. I've also found a condition that could cause it to restore a very old recovery file that was hanging around by mistake. Let me walk through it..
load bst, create/modify a file and compile (without saving it first!). A recovery file is created as there is a modified tab in the ide.
Now.. let's edit the files some more (a lot) but save them to disk prior to every compile.. the recovery file remains on disk and is never updated.
Now crash the ide.. when you re-start, the out-of-date recovery file is restored and loads into the ide as unsaved data.
I can't find any way for that file to overwrite the updated source file on disk unless you manually save it, but stranger things have happened!
In any case, I've squashed that particular bug and we now take care to properly clean up recovery files if there is no need to save one (all tabs are unmodified on compile).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I get a compile error too now ( on #else in zicog_demo.spin ) rather than a lock up [noparse]:)[/noparse]
with the restore file, can't you overwrite the restore file just before compile? and delete it after a restore [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Anyway I'll try again with the latest shortly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Go to Tools->Compiler Preferences->Optimisations and check "Non-Parallax Compatible Extensions".
If it does not compile after than then I'll be out behind the woolshed with a shotgun....
Yes.. that is what was happening.. except when *all* tabs were unmodified the routine bailed early without writing, deleting or over-writing anything..
In that case, it now checks for a restore file and removes it if there is nothing to save. Job done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Find now works again.
One little niggle, the serial terminal windows always seem to open with the first column shifted out of view in Linux. Sometimes the edit window also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.