Timmoore said...
Do you have any plans on adding more pre-processor support? In particular #define macros and #include? I use both in my stuff and currently use a C++ pre-processor to pre-process the files before running propellent. It would be nice to have a better dev environment.
Maybe. I've played with #include on and off, but the thing that has prevented me from implementing it is actually managing the list file output. Once I come up with a solid way of making sure the list file includes the right parts from the right source files with the correct line numbers (and this applies to the errors and warnings also) I'll enable #includes.
Going further and implementing macros is something I've thought about, but not much more. I don't use them myself and again, they have the ability to make things quite untidy for the remainder of the compiler. I _have_ thought about adding a generic pre-processor hook to pipe the source through an external pre-processor as it passes through the compiler, but that then makes it _very_ difficult to report error locations and provide code assistance.
Again, it's not something I'd use myself, so I don't tend to have so much of a push to make it happen.
The tokeniser in the compiler is a pretty basic affair. I've wondered about adding macro expansion to it at the token level. Maybe I need to look at that a bit harder, but that would mean not actually expanding macros out at the source level to human readable text. I guess it'd make it hard to debug when things went wrong with your code.
Timmoore said...
Also what about adding Alt-F, etc. functionality to access menu items. I miss that from bst.
Do you mean shortcuts to open the menus rather than the shortcuts in the menus? I'll have a play with it and see how far I get.
Using an external pre-processor would work for me that is what I use now.
The c++ pre-processors insert #line statements to help the error reporting they contain file and line numbers.
Yes the shortcuts are the underlined character, for example, you can press Alt-F, S for save
Problem.. again, variable tab stops. How do you make it work? At the moment if the next tab stop is 3 characters away, when you hit the tab key you get three spaces. You can't have variable tab stops that match the propeller tool (which I actually quite like) and also have valid hard tab characters.
Really? I tend to use Netbeans and jEdit as my two regular editors (Netbeans for python, and jEdit for everything else) and they both have variable tab stops with hard tab characters. GEdit has them too.
Frankly, I'd be happy with hard tab characters without variable tab stops.
BradC said...
Did you know that bst has three different ways of handling tabs?
a) Smart tabs - Cute but sometimes annoying
b) Fixed tabs like every other editor (but with a configurable tab stop - this can confuse the compiler if you are not careful and its not set to 8) - This does what you are asking above
c) Parallax style variable tabs
This is configurable in the IDE options.
I've experimented with the different options, and they all seem to simply just cause it to insert spaces with different behavior.
Also, all the options just result in spaces when you save the file.
It seems like using hard \t characters would actually make the compilers life easier, as you don't have to guess at indentation issues. It currently works with \t characters from an external editor, but I don't know if you're doing some conversion beforehand.
Sorry to go on about one issue for so long.
BradC said...
Right. How about a compromise. I *like* the ability to be able to click out in no-mans-land and start typing without having to space/tab my way out there. What about if I were to set it up so it linewraps like other editors when using the cursor keys back and forwards. But if you want to "get out there" you can click the mouse there and just start typing?
I don't want to add yet another option, but I kinda like the functionality in the compromise. (Read that as I've just made it work that way and I don't want to go adding extra configuration options)
Awesome.
Post Edited (Fake-Name) : 7/13/2009 1:50:30 AM GMT
Fake-Name said...
[noparse][[/noparse]
I've experimented with the different options, and they all seem to simply just cause it to insert spaces with different behavior.
Also, all the options just result in spaces when you save the file.
It seems like using hard \t characters would actually make the compilers life easier, as you don't have to guess at indentation issues. It currently works with \t characters from an external editor, but I don't know if you're doing some conversion beforehand.
It won't make the compilers life any easier as the tokeniser simply replaces the \t with 8 spaces (this is where it gets untidy).
I always saw tab characters to mean "take the cursor up to the next tab stop" - in the case of TS=8 then it jumps to the next character where X & $7 == 0. This makes it difficult from an editor perspective as the Parallax compiler makes a \t == 8 spaces regardless of initial position. Unfortunately the easy way to do that is to convert the tabs to spaces. Then it's always a known quantity. For example all my (non-spin) source files end with
# vim:ts=4:st=4
But if I fed that into the compiler and I had some lines that were padded with spaces rather than tabs, the indentation would be wrong.
(I like that gedit honours that tag also)
As an example. Let's say you are in a PUB block at column 15 and hit the Tab key. Propeller Tool (and bst in PropTool mode) now takes the cursor out to column 32. Do I build that from a combination of \t + " " for padding? Even though 32 & 7 == 0 I can't simply use \t for padding as the compiler is going to get the indentation wrong (given it does not take into account start column). Or, what happens when a line is 10 characters long and I click in column 53 to write a well spaced comment? Do I use spaces or tabs in the editor to pad the line out?
Using spaces "all the time" is just an easier way of managing the ambiguity.
Remember, the compiler does not "guess" indentation, it simply counts characters [noparse]:)[/noparse]
Also remember I have to maintain 100% compatibility with the Parallax Compiler. (Ok, so I don't _have_ to but it's not something I _want_ to deviate from)
I don't mind discussing any points at length as it often helps me understand precisely what is being requested so I can look further into it. If I understood what you were after 100% there'd be no need for me to discuss it further [noparse];)[/noparse]
Highlight (select) some code by dragging the mouse from right to left. Hit delete (backspace). Instead of being deleted, all the spaces to the left get deleted so now the once highlighted code is up against the left margin. This doesn't happen if selected from left to right.
Highlight (select) some code by dragging the mouse from right to left. Hit delete (backspace). Instead of being deleted, all the spaces to the left get deleted so now the once highlighted code is up against the left margin. This doesn't happen if selected from left to right.
OS X 10.5.7, intel, 0.18.2
Rich H
Wow! What an obscure bug [noparse]:)[/noparse] Thanks Rich.
Hi Brad, no pressure but while we are reporting bugs here's one in Linux:
FIND does not focus and highlight the text box as is usual. So if you hit ctrl-F and expect to type your text it won't work. At present you need to click the text box and highlight the previous text and overtype. A little cumbersome. Also it would help if F3 were enabled to find the next occurrence without having do go through the dialog.
The problem with right to left selection does not seem to occur in Linux as it does in OS X.
Once again, your work is very much appreciated, thank-you.
Peter Jakacki said...
Hi Brad, no pressure but while we are reporting bugs here's one in Linux:
FIND does not focus and highlight the text box as is usual. So if you hit ctrl-F and expect to type your text it won't work. At present you need to click the text box and highlight the previous text and overtype. A little cumbersome. Also it would help if F3 were enabled to find the next occurrence without having do go through the dialog.
Heh, I was showing a friend some Propeller stuff and stumbled across that one last night myself. Most annoying (I don't use find often).
I'll see what I can go about the F3 command. I don't see it being terribly difficult.
Peter Jakacki said...
The problem with right to left selection does not seem to occur in Linux as it does in OS X.
That's most odd. I'm using Ubuntu 8.04 here and I can reproduce it exactly. Select some text right to left, hit the del key and it simply deletes the character one space to the left of the selection. At least it makes it easier to fix when I can reproduce it [noparse]:)[/noparse]
I'll get that one fixed when I manage to get the Alt-tab bug fixed.
I'm using Ubuntu 9.04 and it definitely behaves correctly with right to left selection. I tried variations on this but didn't find any problems. If I do find anything you know that I will be sure to let you know [noparse]:)[/noparse]
What do you want to fix up the Alt-tab bug for, I was just getting used to it!
Regarding the cursor movement / tabbing; I'd be REALLY happy with cursor moving to beginning of next line when end of line is reached - that's been a real pain for me.
As for the tabbing; I can live with it the way it's currently implemented - it'd be nice to have the hard-stops option, but it's not as painful as the EOL cursor movement (for me).
Keep up the excellent work [noparse]:)[/noparse]
BTW: R-L select & delete work fine for me (Windows Vista Home Premium SP2 / BST 1.18.2)
“Before you criticize someone, you should walk a mile in their shoes. That way when you criticize them, you are a mile away from them and you have their shoes.” - Jack Handey.
Regarding the cursor movement / tabbing; I'd be REALLY happy with cursor moving to beginning of next line when end of line is reached - that's been a real pain for me.
I have this working already. I'll get a pre-release out sometime this weekend or monday.
I've got :
- cursor wrap around
- alt-shortcut keys on the menus
- fixed the find box so it focuses the edit box properly
- F3 wired for find-next.
It's time I got it out there to play with.
I'm waiting for some assistance on the underlying toolkit to solve the alt capture problem on Linux though. I'll get an interim release out before that gets fixed I suspect.
I just tried to compile some of my code and it hangs the compiler. The lights flash till they do not flash anymore in the file ppropQLKbd.spin, here are the files. All of them compile separated, except the ioprop.spin. An archive cannot be made because the compilation hangs
An observation on the "Eliminate unused SPIN methods" option.
If you are building an object that you expect to use in a top level application, when you compile the object for information to get sizes you will likely not get a true picture of the object size.
As all unused methods are eliminated, if you are not calling those methods from another object they simply don't get compiled into the final object and as a result your object may appear smaller than it really is.
Just something I noticed as I was playing today.
While I'm here, the 0.18 release exposes information from the compilers symbol list similar to the way Propeller Tool does it.
This is the information revealed when you click on various items in the editor window
Each one is accessed by clicking on the name referenced. For an object it can be anywhere the object name is used (obj#con obj.method)
PUB/PRI Methods - Method size in bytes
Objects - Absolute path of the object file in the PC filesystem
VAR - This only works for global (VAR block) variables, and gives the size and location relative to VBASE of the variable in the propeller memory map.
CON - The value and type of the constant (Same as PropTool)
This information is only available for the current editor tab (the top file last compiled) and remains available until either :
- The editor is switched to another tab
- The current file is changed in any way
F9 is a very quick way of updating this information.
I just tried to compile some of my code and it hangs the compiler. The lights flash till they do not flash anymore in the file ppropQLKbd.spin, here are the files. All of them compile separated, except the ioprop.spin. An archive cannot be made because the compilation hangs
Sweet, I can reproduce this. Great timing! You caught me in the middle of compiling a release. I should have a fix out in about half an hour [noparse]:)[/noparse]
<edit> I meant to say, on Linux now a quick tap of the alt key will restore sane behaviour after alt-tabbing back to the application. There is still a bug, but it's better than it was.
Ok, thought I had a very strange bug whereby I couldn't communicate serially to the Prop but the Spin tool worked find. Turned out to be a broken D+ wire on the USB which caused this strange bug.
The find function is working well but you know I'm lazy and I still have to delete the previous text to type in new text. Maybe you could highlight existing text on focus and I could sleep in an extra 5 minutes a day [noparse]:)[/noparse] (don't stay up too late with this one).
Also that "show block group indicators" in the Spin tool would be handy as well because I seemed to get cross-eyed, especially late at night and I'm not sure about my indentation. What do you think Brad, would it be easy to introduce curly braces rather than relying on indentation alone or is this heresy?
That's a few beers I owe you, you've done a fantastic job so far, you should be grinning (I am).
Peter Jakacki said...
Ok, thought I had a very strange bug whereby I couldn't communicate serially to the Prop but the Spin tool worked find. Turned out to be a broken D+ wire on the USB which caused this strange bug.
I had a similar problem when the usb socket fell off my first prop plug.
Peter Jakacki said...
The find function is working well but you know I'm lazy and I still have to delete the previous text to type in new text. Maybe you could highlight existing text on focus and I could sleep in an extra 5 minutes a day [noparse]:)[/noparse] (don't stay up too late with this one).
I've had this one in the back of my mind for a while actually. My idea was to pre-fill the find box with the word currently under the cursor when it opens up.
Peter Jakacki said...
Also that "show block group indicators" in the Spin tool would be handy as well because I seemed to get cross-eyed, especially late at night and I'm not sure about my indentation. What do you think Brad, would it be easy to introduce curly braces rather than relying on indentation alone or is this heresy?
The first 90% is actually pretty easy, but the last 10% has exceeded my patience several times now.
The biggest issue with block group indicators is I never used them. I do know people would like them though.
Changing to curly braces (which personally I hate, I'd rather begin/end like Pascal personally) would be quite a mangle of the language.
Lookin' forward to that beer. It's thirsty work [noparse];)[/noparse]
The other bug is causing me some grief, let me look at it a bit closer today.
It's odd as the compiler completes my whole regression test, so in theory there is nothing wrong with the way it handles #, but something in your code is tickling a bug there somewhere. I'll get it sorted.
The only two ways to reference something in another object are by constant or by public method. You appear to be trying by Var (which won't work).
obj.method
obj#constant
You can't do
obj#var
It has certainly shown up a nasty bug in my error reporting which has made it a bear to track down. I'll get that sorted ASAP.
I always forget that obj#var does not work. It took me a while to realize where the problem was as it always reported in the same line regardless of the content. Sorry I forgot about -Ox
I always forget that obj#var does not work. It took me a while to realize where the problem was as it always reported in the same line regardless of the content. Sorry I forgot about -Ox
No problem. At least now it reports the error in the correct place in the source. Should make it easier to track down.
Comments
Maybe. I've played with #include on and off, but the thing that has prevented me from implementing it is actually managing the list file output. Once I come up with a solid way of making sure the list file includes the right parts from the right source files with the correct line numbers (and this applies to the errors and warnings also) I'll enable #includes.
Going further and implementing macros is something I've thought about, but not much more. I don't use them myself and again, they have the ability to make things quite untidy for the remainder of the compiler. I _have_ thought about adding a generic pre-processor hook to pipe the source through an external pre-processor as it passes through the compiler, but that then makes it _very_ difficult to report error locations and provide code assistance.
Again, it's not something I'd use myself, so I don't tend to have so much of a push to make it happen.
The tokeniser in the compiler is a pretty basic affair. I've wondered about adding macro expansion to it at the token level. Maybe I need to look at that a bit harder, but that would mean not actually expanding macros out at the source level to human readable text. I guess it'd make it hard to debug when things went wrong with your code.
Do you mean shortcuts to open the menus rather than the shortcuts in the menus? I'll have a play with it and see how far I get.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
The c++ pre-processors insert #line statements to help the error reporting they contain file and line numbers.
Yes the shortcuts are the underlined character, for example, you can press Alt-F, S for save
Really? I tend to use Netbeans and jEdit as my two regular editors (Netbeans for python, and jEdit for everything else) and they both have variable tab stops with hard tab characters. GEdit has them too.
Frankly, I'd be happy with hard tab characters without variable tab stops.
I've experimented with the different options, and they all seem to simply just cause it to insert spaces with different behavior.
Also, all the options just result in spaces when you save the file.
It seems like using hard \t characters would actually make the compilers life easier, as you don't have to guess at indentation issues. It currently works with \t characters from an external editor, but I don't know if you're doing some conversion beforehand.
Sorry to go on about one issue for so long.
Awesome.
Post Edited (Fake-Name) : 7/13/2009 1:50:30 AM GMT
It won't make the compilers life any easier as the tokeniser simply replaces the \t with 8 spaces (this is where it gets untidy).
I always saw tab characters to mean "take the cursor up to the next tab stop" - in the case of TS=8 then it jumps to the next character where X & $7 == 0. This makes it difficult from an editor perspective as the Parallax compiler makes a \t == 8 spaces regardless of initial position. Unfortunately the easy way to do that is to convert the tabs to spaces. Then it's always a known quantity. For example all my (non-spin) source files end with
# vim:ts=4:st=4
But if I fed that into the compiler and I had some lines that were padded with spaces rather than tabs, the indentation would be wrong.
(I like that gedit honours that tag also)
As an example. Let's say you are in a PUB block at column 15 and hit the Tab key. Propeller Tool (and bst in PropTool mode) now takes the cursor out to column 32. Do I build that from a combination of \t + " " for padding? Even though 32 & 7 == 0 I can't simply use \t for padding as the compiler is going to get the indentation wrong (given it does not take into account start column). Or, what happens when a line is 10 characters long and I click in column 53 to write a well spaced comment? Do I use spaces or tabs in the editor to pad the line out?
Using spaces "all the time" is just an easier way of managing the ambiguity.
Remember, the compiler does not "guess" indentation, it simply counts characters [noparse]:)[/noparse]
Also remember I have to maintain 100% compatibility with the Parallax Compiler. (Ok, so I don't _have_ to but it's not something I _want_ to deviate from)
I don't mind discussing any points at length as it often helps me understand precisely what is being requested so I can look further into it. If I understood what you were after 100% there'd be no need for me to discuss it further [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Highlight (select) some code by dragging the mouse from right to left. Hit delete (backspace). Instead of being deleted, all the spaces to the left get deleted so now the once highlighted code is up against the left margin. This doesn't happen if selected from left to right.
OS X 10.5.7, intel, 0.18.2
Rich H
Wow! What an obscure bug [noparse]:)[/noparse] Thanks Rich.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
FIND does not focus and highlight the text box as is usual. So if you hit ctrl-F and expect to type your text it won't work. At present you need to click the text box and highlight the previous text and overtype. A little cumbersome. Also it would help if F3 were enabled to find the next occurrence without having do go through the dialog.
The problem with right to left selection does not seem to occur in Linux as it does in OS X.
Once again, your work is very much appreciated, thank-you.
*Peter*
Heh, I was showing a friend some Propeller stuff and stumbled across that one last night myself. Most annoying (I don't use find often).
I'll see what I can go about the F3 command. I don't see it being terribly difficult.
That's most odd. I'm using Ubuntu 8.04 here and I can reproduce it exactly. Select some text right to left, hit the del key and it simply deletes the character one space to the left of the selection. At least it makes it easier to fix when I can reproduce it [noparse]:)[/noparse]
I'll get that one fixed when I manage to get the Alt-tab bug fixed.
Cheers lads [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
What do you want to fix up the Alt-tab bug for, I was just getting used to it!
Beer's on me when I'm in town.
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Lovin' this IDE - great work
Regarding the cursor movement / tabbing; I'd be REALLY happy with cursor moving to beginning of next line when end of line is reached - that's been a real pain for me.
As for the tabbing; I can live with it the way it's currently implemented - it'd be nice to have the hard-stops option, but it's not as painful as the EOL cursor movement (for me).
Keep up the excellent work [noparse]:)[/noparse]
BTW: R-L select & delete work fine for me (Windows Vista Home Premium SP2 / BST 1.18.2)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
“Before you criticize someone, you should walk a mile in their shoes. That way when you criticize them, you are a mile away from them and you have their shoes.” - Jack Handey.
I have this working already. I'll get a pre-release out sometime this weekend or monday.
I've got :
- cursor wrap around
- alt-shortcut keys on the menus
- fixed the find box so it focuses the edit box properly
- F3 wired for find-next.
It's time I got it out there to play with.
I'm waiting for some assistance on the underlying toolkit to solve the alt capture problem on Linux though. I'll get an interim release out before that gets fixed I suspect.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
I just tried to compile some of my code and it hangs the compiler. The lights flash till they do not flash anymore
Edit: v 0.18.2 on Mac OS X .5.7
Edit: attachment removed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 7/19/2009 9:43:09 AM GMT
If you are building an object that you expect to use in a top level application, when you compile the object for information to get sizes you will likely not get a true picture of the object size.
As all unused methods are eliminated, if you are not calling those methods from another object they simply don't get compiled into the final object and as a result your object may appear smaller than it really is.
Just something I noticed as I was playing today.
While I'm here, the 0.18 release exposes information from the compilers symbol list similar to the way Propeller Tool does it.
This is the information revealed when you click on various items in the editor window
Each one is accessed by clicking on the name referenced. For an object it can be anywhere the object name is used (obj#con obj.method)
PUB/PRI Methods - Method size in bytes
Objects - Absolute path of the object file in the PC filesystem
VAR - This only works for global (VAR block) variables, and gives the size and location relative to VBASE of the variable in the propeller memory map.
CON - The value and type of the constant (Same as PropTool)
This information is only available for the current editor tab (the top file last compiled) and remains available until either :
- The editor is switched to another tab
- The current file is changed in any way
F9 is a very quick way of updating this information.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Sweet, I can reproduce this. Great timing! You caught me in the middle of compiling a release. I should have a fix out in about half an hour [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
That was a curly one to track down!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
<edit> I meant to say, on Linux now a quick tap of the alt key will restore sane behaviour after alt-tabbing back to the application. There is still a bug, but it's better than it was.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Post Edited (BradC) : 7/19/2009 10:36:46 AM GMT
Seems to get speedier with every release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The find function is working well but you know I'm lazy and I still have to delete the previous text to type in new text. Maybe you could highlight existing text on focus and I could sleep in an extra 5 minutes a day [noparse]:)[/noparse] (don't stay up too late with this one).
Also that "show block group indicators" in the Spin tool would be handy as well because I seemed to get cross-eyed, especially late at night and I'm not sure about my indentation. What do you think Brad, would it be easy to introduce curly braces rather than relying on indentation alone or is this heresy?
That's a few beers I owe you, you've done a fantastic job so far, you should be grinning (I am).
*Peter*
I had a similar problem when the usb socket fell off my first prop plug.
I've had this one in the back of my mind for a while actually. My idea was to pre-fill the find box with the word currently under the cursor when it opens up.
The first 90% is actually pretty easy, but the last 10% has exceeded my patience several times now.
The biggest issue with block group indicators is I never used them. I do know people would like them though.
Changing to curly braces (which personally I hate, I'd rather begin/end like Pascal personally) would be quite a mangle of the language.
Lookin' forward to that beer. It's thirsty work [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
The # operator has some problems. Using the code I sent you, remove the duplicated line and you will see something like this:
ioprop - Error at (248,1) Expected Floating point Constant or Constant shr OUTA, #24 ' exposes bits 31..24 (big endian) ^The problematic lines are the ones that say:
(using bstc)
btw: bstc seems not to like #define:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 7/19/2009 7:01:18 PM GMT
You need -Ox at a minimum to use #define.
The other bug is causing me some grief, let me look at it a bit closer today.
It's odd as the compiler completes my whole regression test, so in theory there is nothing wrong with the way it handles #, but something in your code is tickling a bug there somewhere. I'll get it sorted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
The only two ways to reference something in another object are by constant or by public method. You appear to be trying by Var (which won't work).
obj.method
obj#constant
You can't do
obj#var
It has certainly shown up a nasty bug in my error reporting which has made it a bear to track down. I'll get that sorted ASAP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
- Compiler fix for the issue Ale experienced above
- Fix for tab references when file is opened from command line
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
I always forget that obj#var does not work. It took me a while to realize where the problem was as it always reported in the same line regardless of the content. Sorry I forgot about -Ox
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
No problem. At least now it reports the error in the correct place in the source. Should make it easier to track down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Fabulous [noparse]:)[/noparse] I'm actually beginning to think it's starting to come together.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
OS X 10.5.7 intel
Rich H