This is excellent work, mpark. You realize, of course, that having a command-line compiler is the first step in finally integrating Spin with the Eclipse IDE. I think the next step is to build a plugin that provides an editor within Eclipse that is Spin-aware. I would love to work on that, but there are three other projects I need to finish first.
bstc has a couple of bits of code dedicated to case insenstive matching of filenames. Linux enforces case sensitivity, OSX honours it but remains indifferent, Windows has always been insensitive.
I iterate the list of paths (search paths and library paths) and retrieve the entire directory list for each path. I then filter out directories and do a case insensitive string search (just toupper() on both parts) over the entire directory until I find the file I'm looking for.
Yeah, it's starting to ring a bell. Case-sensitive filenames my foot. Whose bright idea was that? No doubt someone who wanted the ability to have different files named tv.spin, Tv.spin, tV.spin, and TV.spin, cuz that would be sooo useful.
This is excellent work, mpark. You realize, of course, that having a command-line compiler is the first step in finally integrating Spin with the Eclipse IDE. I think the next step is to build a plugin that provides an editor within Eclipse that is Spin-aware. I would love to work on that, but there are three other projects I need to finish first.
I wish it was that easy. HomeSpun is actually not what you want to get an Eclipse IDE. HomeSpun is dependent on .Net and ties you to MS or mono to run. I want the same thing and have been investigating for a while and will start over the Holidays. There are tools to help you get started doing this, the one I am looking at is called IMP that requires a lexer/parser. I have been looking at ANTLR to implement the grammar and ASTs required. This will give a fair amount of integration but the ultimate is to do a full implementation like the way Java ide is integrated. That is going to take a while to implement. I hope the first approach will be enough learning to make the final integration easier.
I am sure some will say why? The answer is by doing this I have an integrated tool that is the same as the tools I use in my day job, guess it is the same argument you see with vi vs emacs.
Yeah, it's starting to ring a bell. Case-sensitive filenames my foot. Whose bright idea was that?
Funny how such things go over time. Since the Propeller Tool works this way and that's "the standard," I guess it dictates the compatibility requirements. Not being able to compile some OBEX code without modifications is probably more important for the broader audience than how somebody wants to spell TV.
@Yoda
Do you intend to publish intermediate builds in case others want to contribute?
If you don't force me to use EMACS I might have a little time for it. I can build my own tags file
I guess I'll follow Brad's lead eventually, but don't hold your breath. For the moment, either edit files to say "TV.spin" or make a copy of TV.spin named tv.spin.
Yes Michael, I am sure we can live with the case issues. There would be more pressing "extras" we would like if you have time. #include is a big improvement, thankyou
I just wanted to let you know how impressed I am with Homespun 0.30.
I've updated Catalina to use it (it will be in the next release) and it works a treat on both Linux and Windows. I haven't found a single problem yet!.
The #include has allowed me to eliminate heaps of duplicated code, and being able to define symbols on the command line means I could also eliminate a whole heap of code that I wrote to preprocess all the SPIN files. The overall result is that Catalina compilations now run many times faster, and the code is also a whole lot easier to understand and maintain.
I think I've discovered a bug with Homespin 0.30. It is to do with inconsistent handling of the case of symbols in a $ifdef ... #elseifdef ... #endif chain.
Consider the following example:
CON
#ifdef aaa
MY_CONSTANT = 1
#elseifdef bbb
MY_CONSTANT = 2
#endif
PUB Start | x
x := MY_CONSTANT
Then the following command works (as expected):
homespun homespun_bug.spin -D aaa
and the following command fails (as expected):
homespun homespun_bug.spin -D AAA
HOWEVER, the following command does not work (but I think it should):
homespun homespun_bug.spin -D bbb
and the following command does work (but I think it shouldn't):
I've only had a chance to do some fairly simple tests, but version 030y looks ok - I probably won't get a chance to give it a really good workout till the end of the week.
Hello, I've just installed Catalina on Windows XP Pro SP2 32bit (French) with humespun 0.30, and homespun does not work.
Windows says: "The application could not initialize itself correctly (0xC0000135). Click Ok to stop the application" (Original french text: L'application n'a pas r
Hello, I've just installed Catalina on Windows XP Pro SP2 32bit (French) with humespun 0.30, and homespun does not work.
Hi Alexandre,
both homespun and catdbgfilegen are .NET applications. You need to have the .NET framework installed. Off the top of my head, I can't remember which version (I'm at work at the moment and can't check - if no-one else posts I will let you know when I get home tonight). However, I think it may be .NET 2.0.
@mpark
Hi Michael,
the homespun compiler (my main tool) seems to have problems with some German Umlaut chars.
I use the parallax char set (but would prefer another, cause I think it's ugly).
I have a PropBasic program that uses Print "_
I'm sure Michael will respond when he notices. In the meantime, specify these bytes in hex wherever they occur. Note that you can mix them in with strings of ordinary characters:
I don't know how to handle umlauts etc. and would welcome any advice. Currently, Homespun reads files via StreamReader:
sr = new StreamReader( path+filename );
...
string s = Detab( sr.ReadLine() );
If anyone knows how to change it to read umlauts, please pipe up.
Hi Michael,
I think the problem is that StreamReader defaults to ASCII encoding (only binary values 0 .. 127 allowed). To change the encoding used in your StreamReader class you need to use a different constructor. It will be something like (this is a guess!):
sr = new StreamReader( path+filename, [B]System.Encoding.Unicode [/B]);
Thank you Ross & Michael,
I believe Ross is right with the limitation of Streamreader,
I don't know if it is necessary to go to Unicode (16bit) the full 8bit (0..255) would be sufficient I think.
Fried
Comments
I tried the image with a file that has an #ifndef SYMBOL, #define SYMBOL, #endif in it. After I got the OBJ stuff straight, it compiled fine.
Here's what I ran into with the OBJ stuff ....
steve@steve-laptop:~/Propeller/T2W$ homespun -L ~/spin T2wKbMouse.spin -L /home/steve/spin T2wKbMouse.spin Homespun Spin Compiler 0.30 parsing T2wKbMouse.spin parsing /home/steve/spin/TV_Text.spin Error: /home/steve/spin/TV_Text.spin (44, 8): File not found tv : "tv" ^ steve@steve-laptop:~/Propeller/T2W$ vi ~/spin/TV_Text.spin [COLOR="red"]changed tv : "tv" to upper case tv : "TV" ....[/COLOR] steve@steve-laptop:~/Propeller/T2W$ homespun -L ~/spin T2wKbMouse.spin -L /home/steve/spin T2wKbMouse.spin Homespun Spin Compiler 0.30 parsing T2wKbMouse.spin parsing /home/steve/spin/TV_Text.spin parsing /home/steve/spin/TV.spin compiling T2wKbMouse.spin compiling TV_Text.spin compiling TV.spin writing 32768 bytes to T2wKbMouse.eepromI did raise this a while back.
I wish it was that easy. HomeSpun is actually not what you want to get an Eclipse IDE. HomeSpun is dependent on .Net and ties you to MS or mono to run. I want the same thing and have been investigating for a while and will start over the Holidays. There are tools to help you get started doing this, the one I am looking at is called IMP that requires a lexer/parser. I have been looking at ANTLR to implement the grammar and ASTs required. This will give a fair amount of integration but the ultimate is to do a full implementation like the way Java ide is integrated. That is going to take a while to implement. I hope the first approach will be enough learning to make the final integration easier.
I am sure some will say why? The answer is by doing this I have an integrated tool that is the same as the tools I use in my day job, guess it is the same argument you see with vi vs emacs.
@Yoda
Do you intend to publish intermediate builds in case others want to contribute?
If you don't force me to use EMACS I might have a little time for it. I can build my own tags file
I just wanted to let you know how impressed I am with Homespun 0.30.
I've updated Catalina to use it (it will be in the next release) and it works a treat on both Linux and Windows. I haven't found a single problem yet!.
The #include has allowed me to eliminate heaps of duplicated code, and being able to define symbols on the command line means I could also eliminate a whole heap of code that I wrote to preprocess all the SPIN files. The overall result is that Catalina compilations now run many times faster, and the code is also a whole lot easier to understand and maintain.
Thanks!
Ross.
I think I've discovered a bug with Homespin 0.30. It is to do with inconsistent handling of the case of symbols in a $ifdef ... #elseifdef ... #endif chain.
Consider the following example: Then the following command works (as expected): and the following command fails (as expected): HOWEVER, the following command does not work (but I think it should): and the following command does work (but I think it shouldn't): This is under either Linux or Windows.
Ross.
Hi Michael,
This version seems to have fixed the symbol case bug - but it has added another. When compiling the following file (which I called bug.spin):
where the file my_file.inc contains the following:
With 0.30 I get: But with 0.30x I get: Ross.
Thanks Michael - I'll try it out tomorrow.
Ross.
I've only had a chance to do some fairly simple tests, but version 030y looks ok - I probably won't get a chance to give it a really good workout till the end of the week.
Ross.
Windows says: "The application could not initialize itself correctly (0xC0000135). Click Ok to stop the application" (Original french text: L'application n'a pas r
Hi Alexandre,
both homespun and catdbgfilegen are .NET applications. You need to have the .NET framework installed. Off the top of my head, I can't remember which version (I'm at work at the moment and can't check - if no-one else posts I will let you know when I get home tonight). However, I think it may be .NET 2.0.
Install .NET, and everything should be fine.
Ross.
Hi Michael,
the homespun compiler (my main tool) seems to have problems with some German Umlaut chars.
I use the parallax char set (but would prefer another, cause I think it's ugly).
I have a PropBasic program that uses Print "_
I'm sure Michael will respond when he notices. In the meantime, specify these bytes in hex wherever they occur. Note that you can mix them in with strings of ordinary characters:
[code]DAT
__DATASTART
InLineStr1
BYTE 012,000,0
InLineStr2
BYTE "ABCDEF ",0
InLineStr3
BYTE "123456 ",0
InLineStr4
BYTE "_",$e4,$c4,$fc,$dc,$f6,$d6,"_",0 ' equivalent to "_
If anyone knows how to change it to read umlauts, please pipe up.
Hi Michael,
I think the problem is that StreamReader defaults to ASCII encoding (only binary values 0 .. 127 allowed). To change the encoding used in your StreamReader class you need to use a different constructor. It will be something like (this is a guess!):
Ross.
I believe Ross is right with the limitation of Streamreader,
I don't know if it is necessary to go to Unicode (16bit) the full 8bit (0..255) would be sufficient I think.
Fried
I think it should be:
Any chance to implement that in the near future?
Kind regards,Fried
(This one uses System.Text.Encoding.Default)