Shop OBEX P1 Docs P2 Docs Learn Events
Homespun Spin compiler 0.31: Now open source - Page 11 — Parallax Forums

Homespun Spin compiler 0.31: Now open source

1678911

Comments

  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 16:14
    mpark wrote: »
    Version 0.30 in top post. Added #ifndef.

    I just copied the #ifdef code and changed the sense of a test. That should work, right?
    Yes qualitatively it should. I'll test it later today. Thanks Michael!
  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 18:23
    Michael,
    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.eeprom
    
  • Greg GlennGreg Glenn Posts: 17
    edited 2010-12-17 18:59
    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.
  • mparkmpark Posts: 1,305
    edited 2010-12-17 21:52
    Steve, apparently file names are case-sensitive on your system? I don't know how to handle that. Does BSTC compile TV_Text without modification?
  • jazzedjazzed Posts: 11,803
    edited 2010-12-17 22:29
    mpark wrote: »
    Steve, apparently file names are case-sensitive on your system? I don't know how to handle that. Does BSTC compile TV_Text without modification?
    Yes and yes.
  • BradCBradC Posts: 2,601
    edited 2010-12-17 23:05
    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.
  • mparkmpark Posts: 1,305
    edited 2010-12-18 04:22
    So how the heck do you do that?
  • BradCBradC Posts: 2,601
    edited 2010-12-18 04:36
    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.

    I did raise this a while back.
  • mparkmpark Posts: 1,305
    edited 2010-12-18 07:06
    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.
  • YodaYoda Posts: 132
    edited 2010-12-18 13:31
    Greg Glenn wrote: »
    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.
  • jazzedjazzed Posts: 11,803
    edited 2010-12-18 15:17
    mpark wrote: »
    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 :lol:
  • mparkmpark Posts: 1,305
    edited 2010-12-19 09:06
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2010-12-19 14:56
    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 :)
  • RossHRossH Posts: 5,476
    edited 2011-01-15 20:02
    Hi Michael,

    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.
  • RossHRossH Posts: 5,476
    edited 2011-01-29 18:35
    Hi Michael,

    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):
    homespun homespun_bug.spin -D BBB
    
    This is under either Linux or Windows.

    Ross.
  • mparkmpark Posts: 1,305
    edited 2011-01-30 00:42
    Thanks for the bug report, Ross. Please give 030x (attached here) a try and let me know how it goes. I also added #elseifndef while I was at it.
  • RossHRossH Posts: 5,476
    edited 2011-01-30 03:54
    mpark wrote: »
    Thanks for the bug report, Ross. Please give 030x (attached here) a try and let me know how it goes. I also added #elseifndef while I was at it.

    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):
    #include "my_file.inc"
    
    PUB Start  
    
    where the file my_file.inc contains the following:
    #define SYMBOL_A
    #define SYMBOL_B
    #define SYMBOL_C
    #define SYMBOL_D
    #define SYMBOL_E 
    #define SYMBOL_F
    
    With 0.30 I get:
    Homespun Spin Compiler 0.30
    parsing bug.spin
    compiling bug.spin
    writing 32768 bytes to bug.eeprom
    
    But with 0.30x I get:
    Homespun Spin Compiler 0.30x
    parsing bug.spin
    Index was outside the bounds of the array.
    
    Ross.
  • mparkmpark Posts: 1,305
    edited 2011-01-30 04:30
    Oops, sorry. I probably shouldn't be doing this in my insomnolent state, but I think I've fixed it.
  • RossHRossH Posts: 5,476
    edited 2011-01-30 05:38
    mpark wrote: »
    Oops, sorry. I probably shouldn't be doing this in my insomnolent state, but I think I've fixed it.

    Thanks Michael - I'll try it out tomorrow.

    Ross.
  • RossHRossH Posts: 5,476
    edited 2011-02-01 03:54
    Hi Michael,

    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.
  • allaiksallaiks Posts: 8
    edited 2011-09-07 15:14
    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
  • RossHRossH Posts: 5,476
    edited 2011-09-07 15:47
    allaiks wrote: »
    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.

    Install .NET, and everything should be fine.

    Ross.
  • FriedVFriedV Posts: 77
    edited 2011-10-02 12:43
    @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 "_
  • RossHRossH Posts: 5,476
    edited 2011-10-02 15:57
    Hi Fried,

    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 "_
  • mparkmpark Posts: 1,305
    edited 2011-10-02 18:00
    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.
  • RossHRossH Posts: 5,476
    edited 2011-10-02 18:20
    mpark wrote: »
    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]);
    

    Ross.
  • FriedVFriedV Posts: 77
    edited 2011-10-03 00:33
    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
  • rosco_pcrosco_pc Posts: 465
    edited 2011-10-03 02:03
    RossH wrote: »
    sr = new StreamReader( path+filename, [B]System.Encoding.Unicode [/B]);
    

    I think it should be:
    sr = new StreamReader(path + filename, System.Text.Encoding.Default);
    
  • FriedVFriedV Posts: 77
    edited 2011-10-05 02:35
    @Michael
    Any chance to implement that in the near future?
    Kind regards,Fried
  • mparkmpark Posts: 1,305
    edited 2011-10-06 12:27
    Try this and let me know how it goes (you'll have to rename .txt to .exe of course): homespun031d.txt

    (This one uses System.Text.Encoding.Default)
Sign In or Register to comment.