Since Spin is interpreted, how would you implement inline PASM? There's so much context hidden by the interpreter that I'm not sure that there could ever be a reasonable mechanism to break out of that context momentarily to execute some PASM instructions. Can you give an example of how you would use such a facility, if it could be implemented?
Would you also have a way to provide alternate base directories for searching for objects?
The way this is done in Perl is with a use lib pragma at the head of the program, which prepends directories to the PATH. It's not something that's ever used in programs designed for distribution, but to deal with installation-specific library organizations or to allow for experimentation on a particular system by overriding the regular library. In Spin, I suppose such a thing could be given as a parameter to the OBJ section header.
While I've been working my way around the issue with reserving memory in the DATA segment I'd like support for data structures in spin.
The only other issue I have of any significance has already been debated to death and I seem to be on the losing side which is the whole "blocking by indentation" thing. The current prop tool makes it barely tolerable by using vertical bars along the side to denote blocking but to my knowledge is the only one.
The only other issue I have of any significance has already been debated to death and I seem to be on the losing side which is the whole "blocking by indentation" thing. The current prop tool makes it barely tolerable by using vertical bars along the side to denote blocking but to my knowledge is the only one.
I'm on the losing side of that issue too but I've come to believe it isn't really that important. I've found it pretty easy to get used to using indentation.
The current prop tool makes it barely tolerable by using vertical bars along the side to denote blocking but to my knowledge is the only one.
Saddly I can't;
I use BST on my Linux Workstation and BST does not have the "vertical bars" as a guide for indentation. So, to cope, I check blocking by sliding the text to the left beyond the window frame, while looking for "if" and "else" structures to line up at the frame. The key to make this work is an extra long line that is wider than the normal window. After hours of chasing BUGS due to indentation and program structure, I now routinely create a extra long comment line at the top, just so I can adjust the window.
And therefore, from my perspective; a arbitrary long comment line, is one of the most valuable SPIN Debugging tool.
Since Spin is interpreted, how would you implement inline PASM? There's so much context hidden by the interpreter that I'm not sure that there could ever be a reasonable mechanism to break out of that context momentarily to execute some PASM instructions. Can you give an example of how you would use such a facility, if it could be implemented?
The SpinLMM object enables the Spin interpreter to execute LMM PASM instructions. Of course, SpinLMM isn't inline, but it wouldn't be difficult to implement in the compiler. The Spin interpreter context is actually quite simple. It is determined by the 5 state variables PBASE, VBASE, DBASE, PCURR and DCURR. It would also be nice to implement inline SPASM (Spin Assembly).
BTW, with spin2cpp and CMM mode we could almost eliminate the need for a Spin interpreter. We would just need a CMM interpreter instead. This would allow us to add a lot of features to Spin without having the restriction of fitting the Spin interpreter in cog memory.
The only other issue I have of any significance has already been debated to death and I seem to be on the losing side which is the whole "blocking by indentation" thing. The current prop tool makes it barely tolerable by using vertical bars along the side to denote blocking but to my knowledge is the only one.
I'm on the losing side too. I like eldonb46's solution, though it can get tricky when looking at someone else's code where the indents go 50 - 100 or more lines and the comment line then scrolls off the screen.
Actually none of the prop tools are all that satisfactory. BST and friends don't have those indent lines. And the Proptool has a bug that was introduced a few years ago that stopped it working with cheap USB to serial adapters.
Making the proptool open source might be a start so that bug could be isolated (it wasn't there in the original proptool versions).
My vote for an improvement is global objects, but without an open source compiler I don't think that is possible.
IMHO Spin still is the best language for the propeller. I don't think it would be possible to code that pacman demo I did in any of the other languages (and I really looked hard at trying to do it in C but it is not possible with the current versions of C).
I didn't know about that. Yes, it would be adequate.
Your working directories obviously don't have over 700 .spin files in them like mine does. It's a monolithic mess because I can't specify subdirectories in the OBJ section. I need a way to organize libraries into sub-categories, and a path specification alone is inadequate for the purpose.
Your working directories obviously don't have over 700 .spin files in them like mine does. It's a monolithic mess because I can't specify subdirectories in the OBJ section. I need a way to organize libraries into sub-categories, and a path specification alone is inadequate for the purpose.
-Phil
Looks like BST allows you to add paths in its IDE. Wouldn't that be good enough?
Looks like BST allows you to add paths in its IDE. Wouldn't that be good enough?
No, it doesn't serve the same purpose as being able to organize a library into categories. The PATH variable isn't something you want to monkey with every time you compile a different program. What I want to be able to do is have a main library directory that has subdirectories like Math, IO, Display, etc. IO might be further divided into Serial, I2C, SPI, and so forth. It's the way we organize our other files, but it doesn't work for Spin without being able to pass that information in the OBJ section.
I'm on the losing side of that issue too but I've come to believe it isn't really that important. I've found it pretty easy to get used to using indentation.
Everytime I think I'm over my problem and am used to it I spend an hour or two looking for a bug related to indentation. :-( I can live with it though but I don't see ever getting "over it" or like it.
No, it doesn't serve the same purpose as being able to organize a library into categories. The PATH variable isn't something you want to monkey with every time you compile a different program. What I want to be able to do is have a main library directory that has subdirectories like Math, IO, Display, etc. IO might be further divided into Serial, I2C, SPI, and so forth. It's the way we organize our other files, but it doesn't work for Spin without being able to pass that information in the OBJ section.
-Phil
I like the idea of being able to have a library directory with sub-directories. Like the way C accesses header files and libs.
Thanks for the pointer, as I read your post I remember having tried it in the past but didn't peruse using it. I have no idea why though. I'll have to take another look at it.
No, it doesn't serve the same purpose as being able to organize a library into categories. The PATH variable isn't something you want to monkey with every time you compile a different program. What I want to be able to do is have a main library directory that has subdirectories like Math, IO, Display, etc. IO might be further divided into Serial, I2C, SPI, and so forth. It's the way we organize our other files, but it doesn't work for Spin without being able to pass that information in the OBJ section.
-Phil
PATH like system path? No one suggested that needs to change. The library path(s) can be passed to the compiler with -L or /lib in the case of propellent. This is perfectly acceptable and easy to implement - i.e., it's already done in the open source Spin and other acceptable command line compilers.
I really don't see the utility in these sub-objects. Your explanation is not very convincing to me. I tend to keep all my library files in one or two places. Why do you think everyone needs to use these sub-objects? Please offer one good example where it makes a real difference over finding files in library paths.
Everytime I think I'm over my problem and am used to it I spend an hour or two looking for a bug related to indentation. :-( I can live with it though but I don't see ever getting "over it" or like it.
I've been lucky enough to have had exactly one problem with indentation, no bugs caused by it that I remember, bars or no bars. Everyone has different experiences though.
We have to have a good C, some engineers will demand it (with justification). There are a lot of other people who think they want C, but will end up using SPIN anyway. It is a natural fit for this processor.
We have to have a good C, some engineers will demand it (with justification). There are a lot of other people who think they want C, but will end up using SPIN anyway. It is a natural fit for this processor.
I don't think that it has to be an either or type situation between spin and C.
I really don't see the utility in these sub-objects. Your explanation is not very convincing to me.
Steve, if you're not a heavy or prolific Spin programmer, it really isn't necessary, frankly, that you see the utility or be convinced. But I can tell you that my request is borne of experience, practical -- not ideological -- necessity, and years of frustration from not having the capability. A /lib path helps but does not go far enough. The library itself needs to be organized hierarchically in order to prevent monolithic object glut in one or more magnum directories. Moreover, my experience with systems that permit such organization has convinced me of its value. As the OBEX and default object libraries continue to grow, they will reach a bursting point at which divide-and-conquer can be the only reasonable alternative -- that is, unless organizational anarchy is acceptable.
Hopefully, Roy, Chip, and Jeff will consider the needs of those who actually use Spin to the max and not discount those needs on ideological grounds. This isn't an academic exercise but a real-world problem.
I know some text editors have a "show spaces" function for this purpose. Kedit is one I know of, and I used it with another environment that had indenting. Worked pretty well.
Seems to me, displaying the space character in a slightly different color would resolve this. The tab seems a problem though. I didn't try that one with tabs as mere spaces were enough. Maybe highlight the entire tab area in the same way?
I like the indentation. It's part of what makes SPIN lean. How hard is adding this capability to the IDE? It's worth doing, IMHO, and once done an out of sight, out of mind kind of thing.
Re: Inline.
Really, I'm thinking LMM type code where the SPIN interepeter could just jump into an LMM loop.
I'm in favor of extending SPIN with an LMM type kernel to add functionality too, mostly because priority code could be in PASM, with some less critical things in LMM.
What would be really sweet is to be able to pass addresses just like one can do with the DAT section now, so that the inline section could reference locations by label.
Hopefully, Roy, Chip, and Jeff will consider the needs of those who actually use Spin to the max and not discount those needs on ideological grounds. This isn't an academic exercise but a real-world problem.
-Phil
I use Spin often, and have done many projects with it. Why is my opinion no more important than yours?
I grew tired of the Propeller-tool's inadequacy with respect to library paths and started using BSTC. It fit my needs perfectly.
You mentioned practical experience, but you have yet to show any practical sub-objects examples that would offer any more value than library paths other than some tree of objects. Show a practical problem solving example and I will submit.
I know some text editors have a "show spaces" function for this purpose. Kedit is one I know of, and I used it with another environment that had indenting. Worked pretty well.
Seems to me, displaying the space character in a slightly different color would resolve this. The tab seems a problem though. I didn't try that one with tabs as mere spaces were enough. Maybe highlight the entire tab area in the same way?
I like the indentation. It's part of what makes SPIN lean. How hard is adding this capability to the IDE? It's worth doing, IMHO, and once done an out of sight, out of mind kind of thing.
Re: Inline.
Really, I'm thinking LMM type code where the SPIN interepeter could just jump into an LMM loop.
I'm in favor of extending SPIN with an LMM type kernel to add functionality too, mostly because priority code could be in PASM, with some less critical things in LMM.
What would be really sweet is to be able to pass addresses just like one can do with the DAT section now, so that the inline section could reference locations by label.
Marking the spaces doesn't change the fact that the indentation changes the blocking and syntax/logic of the program. Far better to use braces to denote block limits. A good editor will when the cursor is placed on a brace indicate it's opposite brace making the limits of the block clear! When using an editor like VI you can even put your cursor on a brace and pressing the "%" key in command mode will move the cursor to the opposite brace. With bracing an deleting or adding a space on a line during the debug, rewrite, editing process doesn't change change the blocking of the program.
I can live with it as is but I'll never get to the point of liking it!
It's a different mindset. I found I can grok that and got past it, having few errors over time. For me, it's just not a big deal.
However, it is a core language element I don't see changing either. Violates lean, IMHO. Curious to hear what Chip would say on that. I know the early discussions about it went right to lean and readable, two attributes he wanted to emphasize.
So then, I'm not rocking that boat. Better or not better, really, it can be optimized, and I think that's a good investment. Perhaps add a tool or two for quickly changing the indent from cursor? Press a key combo, or pick an icon, and the whole block gets selected. Arrow right or left, done kind of thing.
I grew tired of the Propeller-tool's inadequacy with respect to library paths and started using BSTC. It fit my needs perfectly.
Good. I'm happy for you -- truly. But that doesn't go far enough for me, and it won't for scores of other users, once the OBEX and default library reach a critical mass.
Show a practical problem solving example and I will submit.
Steve, the problem is that each invocation of the compiler, in your scenario, may require a different /lib directive. In an IDE environment, where is this directive going to come from? What if I have several programs requiring different paths to otherwise monolithic libraries? Should I be required to change the IDE path settings for each program that I compile? No, of course not. That would be nuts. The obvious solution is to set a global, absolute library path via the OS or IDE and more local, relative paths in the programs themselves. And the place to do the latter is in the OBJ section.
Good. I'm happy for you -- truly. But that doesn't go far enough for me, and it won't for scores of other users, once the OBEX and default library reach a critical mass.
I would like to know how many people have had that problem.
Steve, the problem is that each invocation of the compiler, in your scenario, may require a different /lib directive. In an IDE environment, where is this directive going to come from? What if I have several programs requiring different paths to otherwise monolithic libraries? Should I be required to change the IDE path settings for each program that I compile? No, of course not. That would be nuts. The obvious solution is to set a global, absolute library path via the OS or IDE and more local, relative paths in the programs themselves. And the place to do this is in the OBJ section.
Ok, now we can have a discussion (I was beginning to think this was the room for abuse).
So if this is a valid concern (i'm not convinced it is), it impacts what Parallax and I have already considered for the new version of SimpleIDE. My concern is to have fewest possible modes for SimpleIDE for simplicity.
Why do you need more libraries in the first place?
The current idea is to have 2 or more library paths + the local propeller program path files.
The main propeller library files distributed by Parallax can be over-ridden by user library path files.
All library files can be over-ridden by what is in the local propeller program path files
Why is it crazy to set one or more library path or paths in the IDE for a program to be compiled in a given propeller development effort?
I have 2 library paths and one regular path that happens to have the main project code. Why would I ever need more than that?
At this point the feature is not implemented, so it's not as important now, but if someone decides it's important, and actually implements it, I need to plan for it and so will Parallax.
Please answer all this and help me reach some reasonable conclusions about SimpleIDE requirements. I have that other list and a few other suggestions. Dealing with this issue is not on the original spinnyness thread list.
Why is it crazy to set one or more library path or paths in the IDE for a program to be compiled in a given propeller development effort?
Because I might have more than one dev effort going on at the same time and don't want to keep switching back and forth.
Steve, this is not an IDE issue: it's a compiler issue, unless Roy chooses not to implement my OBJ suggestions. The /lib paths submitted to the compiler are merely installation-dependent absolute paths to be expanded upon by further relative paths in the OBJ section. It's up to the compiler to resolve the final path to each object. You're off the hook, once you submit the initial (and, for the most part, unchanging) /lib path to the compiler.
No, it doesn't serve the same purpose as being able to organize a library into categories. The PATH variable isn't something you want to monkey with every time you compile a different program. What I want to be able to do is have a main library directory that has subdirectories like Math, IO, Display, etc. IO might be further divided into Serial, I2C, SPI, and so forth. It's the way we organize our other files, but it doesn't work for Spin without being able to pass that information in the OBJ section.
-Phil
Sorry, I wasn't suggesting that you use the BST path facility to replace your idea of subdirectories, just to allow you to specify multiple places where the Spin compiler could look for the files mentioned in your object paths. I'd like to make sure that I don't have to copy every object that I want to use in a project into a subdirectory of that project. I'd like to be able to find frequently used objects in a common place.
Comments
Since Spin is interpreted, how would you implement inline PASM? There's so much context hidden by the interpreter that I'm not sure that there could ever be a reasonable mechanism to break out of that context momentarily to execute some PASM instructions. Can you give an example of how you would use such a facility, if it could be implemented?
-Phil
-Phil
The only other issue I have of any significance has already been debated to death and I seem to be on the losing side which is the whole "blocking by indentation" thing. The current prop tool makes it barely tolerable by using vertical bars along the side to denote blocking but to my knowledge is the only one.
Saddly I can't;
I use BST on my Linux Workstation and BST does not have the "vertical bars" as a guide for indentation. So, to cope, I check blocking by sliding the text to the left beyond the window frame, while looking for "if" and "else" structures to line up at the frame. The key to make this work is an extra long line that is wider than the normal window. After hours of chasing BUGS due to indentation and program structure, I now routinely create a extra long comment line at the top, just so I can adjust the window.
And therefore, from my perspective; a arbitrary long comment line, is one of the most valuable SPIN Debugging tool.
Eldon - But, it is all fun, with the Prop!
-
BTW, with spin2cpp and CMM mode we could almost eliminate the need for a Spin interpreter. We would just need a CMM interpreter instead. This would allow us to add a lot of features to Spin without having the restriction of fitting the Spin interpreter in cog memory.
I'm on the losing side too. I like eldonb46's solution, though it can get tricky when looking at someone else's code where the indents go 50 - 100 or more lines and the comment line then scrolls off the screen.
Actually none of the prop tools are all that satisfactory. BST and friends don't have those indent lines. And the Proptool has a bug that was introduced a few years ago that stopped it working with cheap USB to serial adapters.
Making the proptool open source might be a start so that bug could be isolated (it wasn't there in the original proptool versions).
My vote for an improvement is global objects, but without an open source compiler I don't think that is possible.
IMHO Spin still is the best language for the propeller. I don't think it would be possible to code that pacman demo I did in any of the other languages (and I really looked hard at trying to do it in C but it is not possible with the current versions of C).
Are any Spin compilers open source?
-Phil
-Phil
Everytime I think I'm over my problem and am used to it I spend an hour or two looking for a bug related to indentation. :-( I can live with it though but I don't see ever getting "over it" or like it.
http://code.google.com/p/pzst/
http://forums.parallax.com/showthread.php?129362-PZST-an-open-source-Propeller-IDE-in-development-Version-1.0.1-released!
I like the idea of being able to have a library directory with sub-directories. Like the way C accesses header files and libs.
Thanks for the pointer, as I read your post I remember having tried it in the past but didn't peruse using it. I have no idea why though. I'll have to take another look at it.
PATH like system path? No one suggested that needs to change. The library path(s) can be passed to the compiler with -L or /lib in the case of propellent. This is perfectly acceptable and easy to implement - i.e., it's already done in the open source Spin and other acceptable command line compilers.
I really don't see the utility in these sub-objects. Your explanation is not very convincing to me. I tend to keep all my library files in one or two places. Why do you think everyone needs to use these sub-objects? Please offer one good example where it makes a real difference over finding files in library paths.
I've been lucky enough to have had exactly one problem with indentation, no bugs caused by it that I remember, bars or no bars. Everyone has different experiences though.
I don't think that it has to be an either or type situation between spin and C.
Hopefully, Roy, Chip, and Jeff will consider the needs of those who actually use Spin to the max and not discount those needs on ideological grounds. This isn't an academic exercise but a real-world problem.
-Phil
I know some text editors have a "show spaces" function for this purpose. Kedit is one I know of, and I used it with another environment that had indenting. Worked pretty well.
Seems to me, displaying the space character in a slightly different color would resolve this. The tab seems a problem though. I didn't try that one with tabs as mere spaces were enough. Maybe highlight the entire tab area in the same way?
I like the indentation. It's part of what makes SPIN lean. How hard is adding this capability to the IDE? It's worth doing, IMHO, and once done an out of sight, out of mind kind of thing.
Re: Inline.
Really, I'm thinking LMM type code where the SPIN interepeter could just jump into an LMM loop.
I'm in favor of extending SPIN with an LMM type kernel to add functionality too, mostly because priority code could be in PASM, with some less critical things in LMM.
What would be really sweet is to be able to pass addresses just like one can do with the DAT section now, so that the inline section could reference locations by label.
I use Spin often, and have done many projects with it. Why is my opinion no more important than yours?
I grew tired of the Propeller-tool's inadequacy with respect to library paths and started using BSTC. It fit my needs perfectly.
You mentioned practical experience, but you have yet to show any practical sub-objects examples that would offer any more value than library paths other than some tree of objects. Show a practical problem solving example and I will submit.
Marking the spaces doesn't change the fact that the indentation changes the blocking and syntax/logic of the program. Far better to use braces to denote block limits. A good editor will when the cursor is placed on a brace indicate it's opposite brace making the limits of the block clear! When using an editor like VI you can even put your cursor on a brace and pressing the "%" key in command mode will move the cursor to the opposite brace. With bracing an deleting or adding a space on a line during the debug, rewrite, editing process doesn't change change the blocking of the program.
I can live with it as is but I'll never get to the point of liking it!
It's a different mindset. I found I can grok that and got past it, having few errors over time. For me, it's just not a big deal.
However, it is a core language element I don't see changing either. Violates lean, IMHO. Curious to hear what Chip would say on that. I know the early discussions about it went right to lean and readable, two attributes he wanted to emphasize.
So then, I'm not rocking that boat. Better or not better, really, it can be optimized, and I think that's a good investment. Perhaps add a tool or two for quickly changing the indent from cursor? Press a key combo, or pick an icon, and the whole block gets selected. Arrow right or left, done kind of thing.
-Phil
So if this is a valid concern (i'm not convinced it is), it impacts what Parallax and I have already considered for the new version of SimpleIDE. My concern is to have fewest possible modes for SimpleIDE for simplicity.
Why do you need more libraries in the first place?
The current idea is to have 2 or more library paths + the local propeller program path files.
The main propeller library files distributed by Parallax can be over-ridden by user library path files.
All library files can be over-ridden by what is in the local propeller program path files
Why is it crazy to set one or more library path or paths in the IDE for a program to be compiled in a given propeller development effort?
I have 2 library paths and one regular path that happens to have the main project code. Why would I ever need more than that?
At this point the feature is not implemented, so it's not as important now, but if someone decides it's important, and actually implements it, I need to plan for it and so will Parallax.
Please answer all this and help me reach some reasonable conclusions about SimpleIDE requirements. I have that other list and a few other suggestions. Dealing with this issue is not on the original spinnyness thread list.
Because I might have more than one dev effort going on at the same time and don't want to keep switching back and forth.
Steve, this is not an IDE issue: it's a compiler issue, unless Roy chooses not to implement my OBJ suggestions. The /lib paths submitted to the compiler are merely installation-dependent absolute paths to be expanded upon by further relative paths in the OBJ section. It's up to the compiler to resolve the final path to each object. You're off the hook, once you submit the initial (and, for the most part, unchanging) /lib path to the compiler.
-Phil