Yep. OpenSpin compiles easily on the Raspbery Pi.
If I remember correctly that last SimpleIDE package I poseted for the Raspberry Pi already uses OpenSpin on the Pi.
I'm going to try and make an update to that.
As noted in the other thread, please don't make a public release of the latest SimpleIDE until I'm ready. If you release early Parallax will kill me.
Roy, a usage question. What am I doing wrong with setting a default path? I've typed spin -I and what I think is a path, but then I get an error back on finding a file that I expect to be in that path. Maybe I'm misunderstanding. Is that path stored somewhere, or do I have to enter it as a command line option each time I want to compile a file?
$ spin -I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
usage: spin
[ -I <path> ] add a directory to the include path
[ -o <path> ] output filename
[ -c ] output only DAT sections
[ -d ] dump out doc mode
[ -q ] quiet mode (suppress banner and non-error text)
[ -v ] verbose output
[ -p ] use preprocessor
[ -D <define> ] add a define (must have -p before any of these)
<name.spin> spin file to compile
$ spin /Users/thomasallen/Desktop/PropSpinCode/Smoke/UCBpm2/UCBpm2_0v14.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
Compiling /Users/thomasallen/Desktop/PropSpinCode/Smoke/UCBpm2/UCBpm2_0v14.spin...
FullDuplexSerial4port.spin : error : Can not find/open file.
This assumes that FullDuplexSerial4Port.spin is in: /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The way I've been using spin is to:
1. Put the spin executable in a known directory for all typical system-level executables (for me that is inside: "/opt/parallax/bin/")
- You would use something like this command on Linux/Unix or in Mac OS X's Terminal app: "$ sudo cp spin /opt/parallax/bin" // assuming "/opt/parallax/bin" already exists.
2. Set "/opt/parallax/bin/" within your $PATH environment variable
- You need to open an existing file named ".profile" or create a new one with the following addition:
# set PATH so it includes /opt/parallax/bin if it exists
if [ -d "/opt/parallax/bin" ] ; then
PATH="/opt/parallax/bin:$PATH"
fi
Then, reboot or use the following command: "$ source .profile" to add that path (for all time!)
3. The above will make spin available from within any directory on your system. Then, the following command(s) should allow you to compile your spin code from within the directory where your spin code resides:
$ cd /PATH-TO-YOUR-SPIN-PROJECT
$ spin -I /PATH-TO-YOUR-INCLUDES/ yourSpinCodeExample.spin
I think that you can have multiple Includes paths, like this "spin -I /FIRST-NCLUDE-PATH/ -I /SECOND-INCLUDE-PATH/ yourSpinCodeExample.spin
Thanks, the -I worked fine. Also as you suggested, two -I for specifying two different library directories:
$ spin
-I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
-I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryParallax
/Users/thomasallen/Desktop/PropSpinCode/Zapr/ZAP_PlayWav__3b.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
Compiling /Users/thomasallen/Desktop/PropSpinCode/Zap/ZAP_PlayWav__3b.spin...
Done.
Program size is 8680 bytes
Following advice on another thread, I had created the directory /usr/local/bin and placed openSpin in that, and now it seems to work without having futzed around with $PATH. Is there an advantage to doing it one way or the other?
I've been building the commands in Terminal using drag and drop. I have Terminal open alongside windows that show my library folders as well as my spin applicaton top file. I drag them in order to the terminal window with a little typing in between when necessary. It took me a while to discover that I could do that.
@dgately, thanks also for the little applescript you showed me in this thread last year, to automate bstl for sending code to people who are innately fearful of Terminal. That's been useful more than that once.
re posts 210-213: so its working but not officially released. I'll wait a bit longer then.
re name: i gather that the tool is called "OpenSPIN" but the command is "spin"? Shouldn't all references to the tool be the same and unambiguous, for example make everything 'OpenSPIN'? We colud always create whatever shortened alias on our own machine....
This stuff is all very new. The actual name of the finished product is still not confirmed as far as I know. The executable has one name, the source repository another, the nick name around here was something else. "Open Spin" is quite a new suggestion that seems to have support. Things will settle in time.
Following advice on another thread, I had created the directory /usr/local/bin and placed openSpin in that, and now it seems to work without having futzed around with $PATH. Is there an advantage to doing it one way or the other?
I've been building the commands in Terminal using drag and drop. I have Terminal open alongside windows that show my library folders as well as my spin applicaton top file. I drag them in order to the terminal window with a little typing in between when necessary. It took me a while to discover that I could do that.
@dgately, thanks also for the little applescript you showed me in this thread last year, to automate bstl for sending code to people who are innately fearful of Terminal. That's been useful more than that once.
/usr/local/bin is a good place for added executables and appears to be in your $PATH by default! I use /opt/parallax/* because propgcc builds that directory tree. Either is good!
Drag & Drop to the Terminal window is a great feature. I never type what can be dragged :cool:.
I'm glad these Mac OS X hints are helpful!
Just for fun, here's a few additions to the .profile file in your home directory that add helpful coloring to the Terminal. :
[SIZE=3]# color prompt
PS1="\[\e[0;31m\][\[\e[1;31m\]\u\[\e[0;34m\]@\h \[\e[32m\]\w\[\e[0;31m]\]\$\[\e[0m\] ";
# highlight grep
alias grep="grep --color=auto"
# color lists
alias ls="ls -G" # list
[/SIZE]
prof_braino,
I have not done a new build since deciding to go with the name OpenSpin. I'll be changing the name of the exe I provide next time I update things.
Cute it is not. Easier to type it is not. One has to remember which is upper case and which is not and then mess with shift key. As a command line incatation that's really annoying.
In the Unix tradition of short and sweet it should be "osc" or just "sc" assuming they are not taken for something else.
Heck, if you want to talk unix, "spin" is the winner. "sp" is probably taken by some obscure system utility already.
I don't like Mixed Case because it REquires that You chord with the tyPing instead of holding dOWN the shIFT key. Mixed Case is For English Lit Majors And PassWords.
You have to trick it into loading a modified kernel. Then you can install linux on the hard drive. There's a good write up here. Some of the info is a little dated. It took me a while to get it to work because I just wanted to load a minimal server distro but the install disks work differently I guess - finally was able to load a full desktop Ubuntu and strip away all the GUI packages -- it was a slow process.
You have to trick it into loading a modified kernel. Then you can install linux on the hard drive. There's a good write up here. Some of the info is a little dated. It took me a while to get it to work because I just wanted to load a minimal server distro but the install disks work differently I guess - finally was able to load a full desktop Ubuntu and strip away all the GUI packages -- it was a slow process.
Thanks for the info! I guess it only works on the old one though.
Thanks for the info! I guess it only works on the old one though.
Correct 1st generation AppleTV runs basically a stripped down version of OS10.4 on an Intel Pentium M- the 2nd and 3rd generations use A5 processor (or newer) and run iOS.
I have been having a look at your compiler, and it seems very promising. However, the preprocessor has a few bugs, and I would like to know whether I should post fixes here, email them directly to you, or perhaps join the google project and submit the changes there? Please let me know.
Th bugs have to do with complex and nested #if[n]def statements not working correctly, problems with reporting unterminated #if[n]def statements, some source lines not being preprocessed at all, and string constants and comments not being handled correctly.
In addition to fixing all the bugs I could find, I have also added some new command line options:
-h : specifies that alternate preprocessor behavior be used. Specifically:
Encountering a #error statement terminates the compilation immediately.
Files included with #include will be found if they exist anywhere in the include paths specified on the command line.
Symbols defined with no value (or defined on the command line) will not be used for macro substitution - they will only be used in #if[n]def statements. For example:
#define FOO
#ifndef FOO
#error FOO is not defined! <-- FOO will be "defined" under either set of rules
#endif
PUB START | FOO,BAR <-- This will generate an error if -h is not used
The reason for some of these changes is that while parsing Spin, the preprocessor currently does macro substitution in some surprising places - for instance, I was confounded for a couple of days before I realized it was substituting "1" when I defined the symbol C3, and then just happened to use $C3 as a hex value in a byte statement. The program compiled but failed to execute correctly, and it took me ages to realize why!
The parser really needs to understand when and where in Spin it is "acceptable" to perform macro substitution (for example, it should never be done within a string constant, in a constant preceded by $ or @, or in a constant with an exponent). In the end, I decided it was simpler to add an option to make the preprocessor not do macro substitution when a symbol is just "#defined" - e.g. #define FOO - unless it has also been assigned a non-null value - e.g. #define FOO 99
-M : specify memory size. The default is 32768, but any size up to 16777216 can be specified, and then dat, binary and eeprom files can be generated up to the specified size.
-b and -e : specify whether a binary or eeprom format output file should be created. The default is binary. The default size for eeproms is 32k (unless overriden by the -M option).
With these changes, this compiler now produces byte for byte identical output to homespun (at least on all the cases I've tried so far), even when compiling LMM, CMM and XMM programs.
Let me know if you'd like a copy of these changes. I'd also like to know how you're getting on with adding a "listing" option - this is something that both bstc and homespun offer, and which the "official" Propeller tool is sadly lacking!
[QUOTE=RossH;1186878 -h : specifies that alternate preprocessor behavior be used. [..][/QUOTE]
For modern, non-legacy tools -h is almost universally the 'help' option, the one which prints the 'Usage' information and exits, e.g.
Hey Ross,
If you could send me patch/diff file(s) as a PM here or submit them as an issue on the google code site, I'll get them integrated. I'll probably change -h to another letter, because, as Tor says, -h should be help on the command line.
That is a significant issue in the preprocessor. I've put it on my list to address properly. Not doing substitutions inside of strings, hex numbers, and wherever else it shouldn't is important. The preprocessor contribution was not fully vetted yet, which is why it was off by default.
I have some local changes that are not up there yet, and will likely need to apply your changes by hand (at least in some of the files), but it shouldn't be too bad.
Hey Ross,
If you could send me patch/diff file(s) as a PM here or submit them as an issue on the google code site, I'll get them integrated. I'll probably change -h to another letter, because, as Tor says, -h should be help on the command line.
That is a significant issue in the preprocessor. I've put it on my list to address properly. Not doing substitutions inside of strings, hex numbers, and wherever else it shouldn't is important. The preprocessor contribution was not fully vetted yet, which is why it was off by default.
I have some local changes that are not up there yet, and will likely need to apply your changes by hand (at least in some of the files), but it shouldn't be too bad.
Roy
Hi Roy,
I've generated a diff file and submitted it as a google issue. I'm fine with you choosing another command line option than -h. How about -a instead?
Roy: Just wondering where your openspin is up to. I see the last windoze build is Feb 2013 - is this the latest???
Hi Ray,
The pre-built version on the "Downloads" tab is version 45, but version 46 is the latest publicly available. To get that version you need to install a subversion client and then use the subversion command specified on the "Source" tab. I can't remember exactly what the differences are.
However, no publicly available version yet includes the various bug fixes and extensions I have added for Catalina, including a limited "listing" function (the main limitation being that it currently only lists the programs DAT segments - which is all I need).
I intend to release a modified version of openspin as part of Catalina 3.11 soon. Just doing some final testing now.
Sorry for the long delay. Only excuses I have are being a fair bit busy with work and other stuff.
Anyway, I've updated the compiler build. It's 49 now. I've updated the binary and source downloads. It's openspin.exe now. See the first post in this thread for the details of the changes.
RossH, thanks for your previous patch file, sorry for the super long delay in getting it applied, modified, and tested. I, also, had to fix a few things to make it produce proper binary output matching the original spin compiler. If you have more changes I can include, then just send 'em to me.
I'm going to be spending more time on for a while, so expect updates more often over the next few months.
Anyway, I've updated the compiler build. It's 49 now. I've updated the binary and source downloads. It's openspin.exe now. See the first post in this thread for the details of the changes..
The change that added "-static" to the Makefile broke building for recent Mac OS X versions (10.7 - 10.8.4).
[myUser@user ~/source/open-source-spin-compiler-read-only]$ make all
g++ -o openspin -DGCC -Wall -g -static -mmacosx-version-min=10.7 SpinSource/openspin.cpp SpinSource/flexbuf.c SpinSource/preprocess.c PropellerCompiler/libopenspin.a
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
make: *** [all] Error 1
Removing "-static" from the makefile fixes this problem.
"A static library is a library of code that can be linked into a binary that will, eventually, be dynamically linked to the system libraries and frameworks."
Comments
As noted in the other thread, please don't make a public release of the latest SimpleIDE until I'm ready. If you release early Parallax will kill me.
$ spin -I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
usage: spin
[ -I <path> ] add a directory to the include path
[ -o <path> ] output filename
[ -c ] output only DAT sections
[ -d ] dump out doc mode
[ -q ] quiet mode (suppress banner and non-error text)
[ -v ] verbose output
[ -p ] use preprocessor
[ -D <define> ] add a define (must have -p before any of these)
<name.spin> spin file to compile
$ spin /Users/thomasallen/Desktop/PropSpinCode/Smoke/UCBpm2/UCBpm2_0v14.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
Compiling /Users/thomasallen/Desktop/PropSpinCode/Smoke/UCBpm2/UCBpm2_0v14.spin...
FullDuplexSerial4port.spin : error : Can not find/open file.
You need to specify the include path as well as your .spin main source file in the same command...
Example:
$ spin -I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME /Users/thomasallen/Desktop/PropSpinCode/Smoke/UCBpm2/UCBpm2_0v14.spin
This assumes that FullDuplexSerial4Port.spin is in: /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The way I've been using spin is to:
1. Put the spin executable in a known directory for all typical system-level executables (for me that is inside: "/opt/parallax/bin/")
- You would use something like this command on Linux/Unix or in Mac OS X's Terminal app: "$ sudo cp spin /opt/parallax/bin" // assuming "/opt/parallax/bin" already exists.
2. Set "/opt/parallax/bin/" within your $PATH environment variable
- You need to open an existing file named ".profile" or create a new one with the following addition:
Then, reboot or use the following command: "$ source .profile" to add that path (for all time!)
3. The above will make spin available from within any directory on your system. Then, the following command(s) should allow you to compile your spin code from within the directory where your spin code resides:
I think that you can have multiple Includes paths, like this "spin -I /FIRST-NCLUDE-PATH/ -I /SECOND-INCLUDE-PATH/ yourSpinCodeExample.spin
dgately
$ spin
-I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryEME
-I /Users/thomasallen/Desktop/PropSpinCode/PropLibraryParallax
/Users/thomasallen/Desktop/PropSpinCode/Zapr/ZAP_PlayWav__3b.spin
Propeller Spin/PASM Compiler (c)2012 Parallax Inc. DBA Parallax Semiconductor.
Compiled on Apr 6 2013
Compiling /Users/thomasallen/Desktop/PropSpinCode/Zap/ZAP_PlayWav__3b.spin...
Done.
Program size is 8680 bytes
Following advice on another thread, I had created the directory /usr/local/bin and placed openSpin in that, and now it seems to work without having futzed around with $PATH. Is there an advantage to doing it one way or the other?
I've been building the commands in Terminal using drag and drop. I have Terminal open alongside windows that show my library folders as well as my spin applicaton top file. I drag them in order to the terminal window with a little typing in between when necessary. It took me a while to discover that I could do that.
@dgately, thanks also for the little applescript you showed me in this thread last year, to automate bstl for sending code to people who are innately fearful of Terminal. That's been useful more than that once.
re name: i gather that the tool is called "OpenSPIN" but the command is "spin"? Shouldn't all references to the tool be the same and unambiguous, for example make everything 'OpenSPIN'? We colud always create whatever shortened alias on our own machine....
This stuff is all very new. The actual name of the finished product is still not confirmed as far as I know. The executable has one name, the source repository another, the nick name around here was something else. "Open Spin" is quite a new suggestion that seems to have support. Things will settle in time.
/usr/local/bin is a good place for added executables and appears to be in your $PATH by default! I use /opt/parallax/* because propgcc builds that directory tree. Either is good!
Drag & Drop to the Terminal window is a great feature. I never type what can be dragged :cool:.
I'm glad these Mac OS X hints are helpful!
Just for fun, here's a few additions to the .profile file in your home directory that add helpful coloring to the Terminal. :
dgately
I have not done a new build since deciding to go with the name OpenSpin. I'll be changing the name of the exe I provide next time I update things.
Thanks Roy. I'm planning to include this in the resource package for the kids+robots project I'm working on. Little details like this go a long way!
Cute it is not. Easier to type it is not. One has to remember which is upper case and which is not and then mess with shift key. As a command line incatation that's really annoying.
In the Unix tradition of short and sweet it should be "osc" or just "sc" assuming they are not taken for something else.
I don't like Mixed Case because it REquires that You chord with the tyPing instead of holding dOWN the shIFT key. Mixed Case is For English Lit Majors And PassWords.
Paul
I have been having a look at your compiler, and it seems very promising. However, the preprocessor has a few bugs, and I would like to know whether I should post fixes here, email them directly to you, or perhaps join the google project and submit the changes there? Please let me know.
Th bugs have to do with complex and nested #if[n]def statements not working correctly, problems with reporting unterminated #if[n]def statements, some source lines not being preprocessed at all, and string constants and comments not being handled correctly.
In addition to fixing all the bugs I could find, I have also added some new command line options:
-h : specifies that alternate preprocessor behavior be used. Specifically:
-M : specify memory size. The default is 32768, but any size up to 16777216 can be specified, and then dat, binary and eeprom files can be generated up to the specified size.
-b and -e : specify whether a binary or eeprom format output file should be created. The default is binary. The default size for eeproms is 32k (unless overriden by the -M option).
With these changes, this compiler now produces byte for byte identical output to homespun (at least on all the cases I've tried so far), even when compiling LMM, CMM and XMM programs.
Let me know if you'd like a copy of these changes. I'd also like to know how you're getting on with adding a "listing" option - this is something that both bstc and homespun offer, and which the "official" Propeller tool is sadly lacking!
Ross.
For modern, non-legacy tools -h is almost universally the 'help' option, the one which prints the 'Usage' information and exits, e.g.
If you could send me patch/diff file(s) as a PM here or submit them as an issue on the google code site, I'll get them integrated. I'll probably change -h to another letter, because, as Tor says, -h should be help on the command line.
That is a significant issue in the preprocessor. I've put it on my list to address properly. Not doing substitutions inside of strings, hex numbers, and wherever else it shouldn't is important. The preprocessor contribution was not fully vetted yet, which is why it was off by default.
I have some local changes that are not up there yet, and will likely need to apply your changes by hand (at least in some of the files), but it shouldn't be too bad.
Roy
Hi Roy,
I've generated a diff file and submitted it as a google issue. I'm fine with you choosing another command line option than -h. How about -a instead?
Ross.
I'm still interested to hear if you have made any progress on adding a 'listing' option to this compiler.
Ross.
It's on my list to add some form of listing option. It's lower priority than several other things right now.
Roy
Hi Ray,
The pre-built version on the "Downloads" tab is version 45, but version 46 is the latest publicly available. To get that version you need to install a subversion client and then use the subversion command specified on the "Source" tab. I can't remember exactly what the differences are.
However, no publicly available version yet includes the various bug fixes and extensions I have added for Catalina, including a limited "listing" function (the main limitation being that it currently only lists the programs DAT segments - which is all I need).
I intend to release a modified version of openspin as part of Catalina 3.11 soon. Just doing some final testing now.
Ross.
Anyway, I've updated the compiler build. It's 49 now. I've updated the binary and source downloads. It's openspin.exe now. See the first post in this thread for the details of the changes.
RossH, thanks for your previous patch file, sorry for the super long delay in getting it applied, modified, and tested. I, also, had to fix a few things to make it produce proper binary output matching the original spin compiler. If you have more changes I can include, then just send 'em to me.
I'm going to be spending more time on for a while, so expect updates more often over the next few months.
The change that added "-static" to the Makefile broke building for recent Mac OS X versions (10.7 - 10.8.4).
Removing "-static" from the makefile fixes this problem.
Note: Read the following for an explanation of why -static won't work for Mac OS X: http://developer.apple.com/library/mac/qa/qa1118/_index.html
dgately
"A static library is a library of code that can be linked into a binary that will, eventually, be dynamically linked to the system libraries and frameworks."
Who came up with this definition?