Visual Studio Code

135

Comments

  • Seairth,
    I figured it out! It turns out that this is the purpose for lookaheads!
    Brilliant. You are regexp master now,

    Actually I was wondering how it's even possible to do this with regexps. I mean what happens in "CON" or whatever is inside a comment? Or other weird situations.
    by the way, I've also started working on a Spin version for the Propeller. Once I figure out a few more items, like the LanguageServer stuff, I will be adding that to the repository as well. In that case, I should also be able to use one of the existing command-line tools to compile and load the binaries. Which one(s) would you all recommend?
    A couple of thoughts:

    1) Spin syntax highlighting should be an extension by itself, nice and simple.

    2) Similarly a Spin compiler should be a separate extension.

    3) And similarly any loader should be it's own extension.

    4) I don't recommend using any command line compilers or loaders for Spin.

    The thing about item 4) is that we can compile the C++ source of OpenSpin into Javascript with Emscripten. The resulting JS Spin compiler can be run as a "Language Server" to get the Spin compiled into binaries.

    We know this is possible because msrobots and I have done it. Using web workers in the browser. See here:

    http://87.100.174.67/lab/spine.html

    Which is a proof of concept. You have to hit the "Spawn worker", "Send files to worker", "Compile" and "Get binary" buttons to drive the thing,

    Or here:

    http://87.100.174.67/lab/editor17/editor17.html

    Which is msrobots Spin IDE in the browser. Sadly not working well on my server.

    The other thing is that I thought someone had made a Propeller loader in Javascript running under node.js already. If not, we can make one. Again as a worker process.

    With that in place we have a cross-platform Spin IDE all done in JS.

    Anyway, you are streets ahead of me. I only just got the "Hello world" code extension working.


  • David Betz,
    I've noticed that the Microsoft Surface is used on a number of the TV shows my wife and I watch.
    A year or so there was a great news story about MS giving Surface tabs to TV sports reporters for some big Yankee baseball match or whatever. Thing was someone got some video shots of how the sports reporters had their Surface tabs propped up in front of them on their desks, prominently on display for the TV coverage. BUT they were actually using iPads lying down behind them!
  • ...and there's more!!!

    Visual Studio Code works on Raspberry Pi too!! (Disclaimer: you need about 3 hours to build and install things and can't be squeamish about installing and building stuff on your RasPi.)

    High level steps:

    1) sudo apt-get remove node node-legacy # yup, you need to get rid of what's installed
    2) grab the latest nodejs source tarball from node.org # at least you'll have latest and greatest node!!
    3) build node on your RasPi (with older nodes, this would take about 10-15 minutes), with the latest node, this takes 2 hours!! (go have lunch, I did....and it still wasn't done!)
    4) grab visual studio code repostory and build it (another 20-30 minutes)
    git clone https://github.com/microsoft/vscode
    cd vscode
    ./scripts/npm.sh install --arch=armhf
    (you will see some complaints go by about deprecated stuff...and some errors about windows-mutex - it's for windows, who cares!)
    5) Now, you should be ready to run vscode for the first time - and guess what, it needs to do some more building and compiling and code checking and emitting (thi takes about 8 minutes)
    ./scripts/code.sh
    6) FINALLY, you should have a blank editor window pop up as the vscode editor actually starts!!
    7) ...by now, the sun has gone down, your family has gone to bed and your dog has left you for the couch...but you DO have what appears to be a working vscode on your Raspberry Pi!!!

    Why?? No clue, there isn't any pressing need since there are more than enough editing tools to use. I know, because you could! That's why!!!

    Startup time after that initial one is about 15-20 seconds to go from command line to running editor. Geany starts up in about 2-3 seconds. VIM? Well, don't blink!

  • mindrobots wrote: »
    Why?? No clue, there isn't any pressing need since there are more than enough editing tools to use. I know, because you could! That's why!!!

    Startup time after that initial one is about 15-20 seconds to go from command line to running editor. Geany starts up in about 2-3 seconds. VIM? Well, don't blink!

    Neat! Why, of course, is because it can potentially make for a great Propeller IDE.

    The startup performance is a bit unfortunate. I wonder if node.js 6 will help at all. Or is that what you just installed? I'm guessing that VSCode is a larger package than Geany and VIM, especially if including the node modules that need to load, so some of this could also be filesystem-related.
  • SeairthSeairth Posts: 2,471
    edited 2016-04-29 - 19:02:34
    Seairth wrote: »
    mindrobots wrote: »
    Why?? No clue, there isn't any pressing need since there are more than enough editing tools to use. I know, because you could! That's why!!!

    Startup time after that initial one is about 15-20 seconds to go from command line to running editor. Geany starts up in about 2-3 seconds. VIM? Well, don't blink!

    Neat! Why, of course, is because it can potentially make for a great Propeller IDE.

    The startup performance is a bit unfortunate. I wonder if node.js 6 will help at all. Or is that what you just installed? I'm guessing that VSCode is a larger package than Geany and VIM, especially if including the node modules that need to load, so some of this could also be filesystem-related.

    btw, what was your RPi setup?

    ( edit: ARGH! I hate when I reply when I mean to edit! I blame the forum software and/or page layout. Does "Edit" really need to be hidden in a pop-up menu? Just conditionally put an "Edit" button next to "Quote"! )
  • Cricket MATCH:
    cricket-match.jpg
    Match:
    match.jpeg
    Baseball GAME:
    baseball-game.jpg

    Surface Pro - the Official Tablet of the NFL??

    surface%20pro.png
    620 x 388 - 57K
    150 x 60 - 1K
    500 x 333 - 71K
    632 x 556 - 951K
  • Heater.Heater. Posts: 21,233
    edited 2016-04-29 - 19:49:37
    mindrobots,

    Brilliant. That was going to be my next experiment.

    So I did it anyway. The wife did not kick me out. The dog is still on the couch.

    Why? Because I took a short cut. Why compile node when you can get it pre-compiled from here:
    https://nodejs.org/download/release/v6.0.0/
    $ cd /usr/local
    $ sudo wget https://nodejs.org/download/release/v6.0.0/node-v6.0.0-linux-armv7l.tar.gz
    $ sudo tar --strip-components=1 -xvf node-v6.0.0-linux-armv7l.tar.gz
    $ node --version
    v6.0.0
    $
    
    This is the normal way I get node on to any machine. As far as I recall node is not installed by default on the Pi.

    Then I follow the rest of your instructions. Which all work as far as I can tell. I end up with:
    bla bla Gtk: cannot open display:
    
    Which is fair enough because I'm running headless and logged in over ssh.

    So I have no idea if this actually works or not.

    Why??

    Because we are going to make a Propeller IDE out of this.

    Aside: It would speed things up a lot if MS had not written most of it in Typescript. All that TS to JS compilation takes ages. Just write your code in JS already!


    Edit: It works! On a whim I ran it via ssh on my PC:
    ssh pi@192.168.1.124 -X /home/pi/vscode/scripts/code.sh
    
    After an age and many grumbling messages the VSC window opened on my PC !
  • Glad to hear about the wife and dog! :) An old nodejs comes on the Pi with Jessie (0.11.6 or some such). I wanted to build node anyway because I had used it as a benchmark when playing with Pi and SSD configurations....I thought I'd "benchmark the RasPi3 - that's why the change in build times surprised me so much.

    I've been playing a bit with it and get "Extensions host terminated unexpectedly. Please reload the window to recover." messages on a "so far" random basis as I try things. The are some issues on the MS github that say this is often due to memory and heap issues. I think we're trying to stuff 10 pounds of code into a 5 pound computer when running this on our poor little Raspberry Pi's.

    There are examples of people using VNC to remote into their Pi and running vscode....I don't have a Pi set up for that, so I couldn't test it. I'm not sure it would help much with the memory issues. We'll just need to wait for the "big memory" Raspi to be announced :D
  • Seairth wrote: »
    by the way, I've also started working on a Spin version for the Propeller. Once I figure out a few more items, like the LanguageServer stuff, I will be adding that to the repository as well. In that case, I should also be able to use one of the existing command-line tools to compile and load the binaries. Which one(s) would you all recommend?

    Sounds like there will be lots of versions of Spin for the P2 soon :). fastspin (aka spin2cpp) support for P2 is coming along, and the adventurous can check out the source from https://github.com/totalspectrum/spin2cpp. Hello world works; here's the source (which can compile and run on Linux, Prop1, and Prop2):
    ''
    '' simple hello world that works on PC, Propeller, or Prop2
    ''
    '' to compile for PC:
    ''   spin2cpp --cc=gcc -DPC --elf -o Hello HelloWorld.spin
    '' to compile for Propeller
    ''   spin2cpp --asm --binary --code=hub -o hello.binary HelloWorld.spin
    '' to compiler for Prop2:
    ''   spin2cpp --p2 --asm -o hello.p2asm --code=hub HelloWorld.spin
    ''
    CON
      _clkmode = xtal1 + pll16x
      _clkfreq = 80_000_000
      
    VAR
      byte txpin
      byte rxpin
      long baud
      long txmask
      long bitcycles
       
    #ifdef PC
    '' we will be using stdio, so force it to
    '' be included
    {++
    #include <stdio.h>
    #include <stdlib.h>
    }
    #endif
    
    ''
    '' print out hello, world
    ''
    PUB hello
      start(31, 30, 0, 115200)
      repeat
        str(string("hello, world!", 13, 10))
      
    ''
    '' code: largely taken from FullDuplexSerial.spin
    ''
    
    PUB start(rx_pin, tx_pin, mode, baudrate)
    #ifndef PC
      baud := baudrate
      bitcycles := _clkfreq / baudrate
      txpin := tx_pin
      txmask := (1<<txpin)
      rxpin := rx_pin
    #endif
      return 1
      
    PUB tx(c) | val, waitcycles
    #ifdef PC
      '' just emit direct C code here
      {++
      putchar(c);
      }
    #else
    # ifdef __P2__
      OUTB |= txmask
      DIRB |= txmask
    # else
      OUTA |= txmask
      DIRA |= txmask
    #endif
      val := (c | 256) << 1
      waitcycles := CNT
      repeat 10
         waitcnt(waitcycles += bitcycles)
    #ifdef __P2__
         if (val & 1)
           OUTB |= txmask
         else
           OUTB &= !txmask
         val >>= 1
    #else
         if (val & 1)
           OUTA |= txmask
         else
           OUTA &= !txmask
         val >>= 1
    #endif
    #endif
    
    PUB str(s) | c
      REPEAT WHILE ((c := byte[s++]) <> 0)
        tx(c)
    

    and here's the P2 assembly it produces:
    CON
    	_clkmode = 1032
    	_clkfreq = 80000000
    DAT
    	org	0
    entry
    	mov ptra, ##@stackspace
    	jmp #@hubentry
    
    divide_
           abs     muldiva_,muldiva_     wc       'abs(x)
           muxc    itmp2_,#%11                    'store sign of x
           abs     muldivb_,muldivb_     wc,wz    'abs(y)
     if_c  xor     itmp2_,#%10                    'store sign of y
           setq    #0
           qdiv    muldiva_, muldivb_
           getqx   muldivb_
           getqy   muldiva_
           test    itmp2_,#1        wc       'restore sign, remainder
           negc    muldiva_,muldiva_ 
           test    itmp2_,#%10      wc       'restore sign, division result
           negc    muldivb_,muldivb_
           reta
    
    _start_rx_pin
    	long	0
    _start_tx_pin
    	long	0
    _str_c
    	long	0
    _str_s
    	long	0
    _tx__idx__0001
    	long	0
    _tx_val
    	long	0
    _tx_waitcycles
    	long	0
    arg1
    	long	0
    arg2
    	long	0
    arg3
    	long	0
    arg4
    	long	0
    itmp1_
    	long	0
    itmp2_
    	long	0
    muldiva_
    	long	0
    muldivb_
    	long	0
    objptr
    	long	@objmem
    ptr_L__0004_
    	long	@L__0004
    result1
    	long	0
    start_tmp001_
    	long	0
    start_tmp002_
    	long	0
    str_tmp001_
    	long	0
    tx_tmp002_
    	long	0
    	fit	496
    	orgh	$400
    hubentry
    
    _hello
    	mov	arg1, #31
    	mov	arg2, #30
    	mov	arg3, #0
    	mov	arg4, ##115200
    	calla	#@_start
    L__0002
    	mov	arg1, ptr_L__0004_
    	calla	#@_str
    	jmp	#@L__0002
    _hello_ret
    	reta
    
    _start
    	mov	_start_rx_pin, arg1
    	mov	_start_tx_pin, arg2
    	mov	muldivb_, arg4
    	wrlong	muldivb_, objptr
    	mov	muldiva_, ##80000000
    	calla	#divide_
    	add	objptr, #8
    	wrlong	muldivb_, objptr
    	add	objptr, #4
    	wrbyte	_start_tx_pin, objptr
    	mov	start_tmp001_, #1
    	rdbyte	start_tmp002_, objptr
    	shl	start_tmp001_, start_tmp002_
    	sub	objptr, #8
    	wrlong	start_tmp001_, objptr
    	add	objptr, #9
    	wrbyte	_start_rx_pin, objptr
    	sub	objptr, #13
    	mov	result1, #1
    _start_ret
    	reta
    
    _tx
    	add	objptr, #4
    	rdlong	tx_tmp002_, objptr
    	or	OUTB, tx_tmp002_
    	sub	objptr, #4
    	or	DIRB, tx_tmp002_
    	mov	_tx_val, arg1
    	or	_tx_val, #256
    	shl	_tx_val, #1
    	getct	result1
    	mov	_tx_waitcycles, result1
    	mov	_tx__idx__0001, #10
    L__0005
    	add	objptr, #8
    	rdlong	tx_tmp002_, objptr
    	sub	objptr, #8
    	add	_tx_waitcycles, tx_tmp002_
    	mov	arg1, _tx_waitcycles
    	addct1	arg1, #0
    	waitct1
    	test	_tx_val, #1 wz
     if_e	jmp	#@L__0008
    	add	objptr, #4
    	rdlong	tx_tmp002_, objptr
    	sub	objptr, #4
    	or	OUTB, tx_tmp002_
    	jmp	#@L__0009
    L__0008
    	add	objptr, #4
    	rdlong	tx_tmp002_, objptr
    	sub	objptr, #4
    	andn	OUTB, tx_tmp002_
    L__0009
    	shr	_tx_val, #1
    	djnz	_tx__idx__0001, #@L__0005
    _tx_ret
    	reta
    
    _str
    	mov	_str_s, arg1
    L__0010
    	mov	str_tmp001_, _str_s
    	add	_str_s, #1
    	rdbyte	_str_c, str_tmp001_ wz
     if_ne	mov	arg1, _str_c
     if_ne	calla	#@_tx
     if_ne	jmp	#@L__0010
    _str_ret
    	reta
    
    L__0004
    	byte	"hello, world!"
    	byte	13
    	byte	10
    	byte	0
    	long
    objmem
    	long	$00000000
    	long	$00000000
    	long	$00000000
    	long	$00000000
    stackspace
    	long	0
    

    As you can see although it does run it's not particularly optimized for the P2 yet. The DAT section processing is also very incomplete still (a lot of P2 instructions aren't recognized yet). But with hello world working I hope the pace should pick up now.

  • Seairth wrote: »
    Seairth wrote: »
    mindrobots wrote: »
    Why?? No clue, there isn't any pressing need since there are more than enough editing tools to use. I know, because you could! That's why!!!

    Startup time after that initial one is about 15-20 seconds to go from command line to running editor. Geany starts up in about 2-3 seconds. VIM? Well, don't blink!

    Neat! Why, of course, is because it can potentially make for a great Propeller IDE.

    The startup performance is a bit unfortunate. I wonder if node.js 6 will help at all. Or is that what you just installed? I'm guessing that VSCode is a larger package than Geany and VIM, especially if including the node modules that need to load, so some of this could also be filesystem-related.


    btw, what was your RPi setup?

    RasPi 3 - no overclocking, Raspbian Jessie (maybe 1 release back?)
    1GB of memory :D

    I had just installed nodje 6 so it either helped (or not!).

    Startup time isn't unreasonable if you think of it as an IDE like Eclipse - start it in the morning and do almost everythign you need to do from inside Eclipse during the day. Twenty seconds is acceptable for that.

    vscode itself seems pretty responsive once it is started. Barring the memory issues, it is certainly usable as an editor. It tells me that I have no extensions installed at this time - I'm not sure if that is the default or if it is because my Extension Host terminated...therefore, no extensions. When I get some more play time, I'll try your extension and see what that does.

    I could try a SD card with /swap - it may allow Jessie to offload enough unused cruft from memory to waddle through vscode. I ususally don't do /swap on Raspi images.

    (**Interesting mindset thing: I said "when I get more playtime" because I am doing this on my Raspberry Pi sitting on my desk at work...old mindset says I won't be back to that computer until Monday..... New mindset says "unplug the little thing, toss it your briefcase and play with it at home!" Or even "pop out the SD card and take it home to plug into your Pi at home!" I like this world of tiny/cheap computers!!!)

  • Hmm...code takes 4 or 5 percent of my memory on a 4GB RAM PC. Say 200MB. That should fit in a Pi OK.

    I have to get a display hooked up to a Pi here and see how it goes.

  • Root cause statements were strictly speculation. I'm management, not engineering !

    Be glad I'm not marketing!! :D
  • mindrobots,

    Management, engineering, marketing, I don't care.

    I'm glad you are nerdy enough to be doing such things as a hobby.

    Even at risk of the dog leaving home!

  • jmgjmg Posts: 14,474
    ersmith wrote: »
    As you can see although it does run it's not particularly optimized for the P2 yet. The DAT section processing is also very incomplete still (a lot of P2 instructions aren't recognized yet). But with hello world working I hope the pace should pick up now.
    Cool!
    It does not need to be particularly optimized, at this stage.
    Can it access the Smart Pins ?

    Nice features: I see conditionals and in-line C, is there also an in-line ASM form?
  • jmgjmg Posts: 14,474
    Heater. wrote: »
    4) I don't recommend using any command line compilers or loaders for Spin.

    The thing about item 4) is that we can compile the C++ source of OpenSpin into Javascript with Emscripten. The resulting JS Spin compiler can be run as a "Language Server" to get the Spin compiled into binaries.

    Nice ideal, but care is needed - take a look at those startup times on a RaspPi for the various IDE.
    BIG ratios are possible, with those ever-more layers of fluff.

    If JS Spin compiler is woefully slow, it rather defeats the purpose.

    Many production environments prefer command line compilers and loaders.
  • jmg,

    I know what you mean. I seem to have wasted half my working life waiting for compilers to do their thing. C++ is the worst. Slow enough to waste time, but not enough time
    that you can do something else whilst waiting.

    Who cares about "production environments"? If it takes all night to compile code for production that is OK. Besides there is no "production environment" for the Propeller.

    What is important is that when a developer is doing his thing, developing, it happens in as close to possible real time. Like with the Propeller Tool.

    OK, you have laid down the challenge. How fast can we compile Spin, using OpenSpin in Javascript, on a Raspberry Pi.

    I'll be back....






  • Heater. wrote: »
    Seairth,
    I figured it out! It turns out that this is the purpose for lookaheads!
    Brilliant. You are regexp master now,

    Actually I was wondering how it's even possible to do this with regexps. I mean what happens in "CON" or whatever is inside a comment? Or other weird situations.

    It took me a little bit to figure this one out. Here's how it generally goes:

    * The regular expression matches occur in the order they (or more accurately, the associated pattern object) occur in the language file.
    * If a match is made, the matching text is marked with a name/token. Then, the pattern matching starts over again from the first character following the prior match.
    * I read a note somewhere that multi-line matches are not supported. So, match searches only work through one line at a time.
    * So, the upshot is that the "comments" pattern is first in the list.
    * Then sections (con, dat, etc.). In my case, each of the sections contains it's own nested set of patterns. Once you have matched the section "begin" pattern, only the nested patterns are evaluated until you encounter the section "end" pattern.
    * Because only the nested patterns are evaluated inside each section, you must repeat the "comments" pattern inside the nested list (again, at the beginning to be evaluated first).
    * Because you don't want to have to repeat the entire pattern definition for "comments" in every nested list (and the main list), you can define an optional "repository", which contains re-usable patterns. So, you put the "comments" pattern in the repository part of the language file, then you include "#comments" wherever you want the pattern to be evaluated.

    That's about it. The rest can be understood by reading the TextMate or Sublime documentation. If VSCode provides a similar page, I haven't come across it yet.
    Heater. wrote: »
    Seairth,
    by the way, I've also started working on a Spin version for the Propeller. Once I figure out a few more items, like the LanguageServer stuff, I will be adding that to the repository as well. In that case, I should also be able to use one of the existing command-line tools to compile and load the binaries. Which one(s) would you all recommend?
    A couple of thoughts:

    1) Spin syntax highlighting should be an extension by itself, nice and simple.

    2) Similarly a Spin compiler should be a separate extension.

    3) And similarly any loader should be it's own extension.

    4) I don't recommend using any command line compilers or loaders for Spin.

    The thing about item 4) is that we can compile the C++ source of OpenSpin into Javascript with Emscripten. The resulting JS Spin compiler can be run as a "Language Server" to get the Spin compiled into binaries.

    We know this is possible because msrobots and I have done it. Using web workers in the browser. See here:

    http://87.100.174.67/lab/spine.html

    Which is a proof of concept. You have to hit the "Spawn worker", "Send files to worker", "Compile" and "Get binary" buttons to drive the thing,

    Or here:

    http://87.100.174.67/lab/editor17/editor17.html

    Which is msrobots Spin IDE in the browser. Sadly not working well on my server.

    The other thing is that I thought someone had made a Propeller loader in Javascript running under node.js already. If not, we can make one. Again as a worker process.

    With that in place we have a cross-platform Spin IDE all done in JS.

    I'd still include a parser in the syntax extension. This will allow integration with Intellisense and CodeLens, which I find to be a major productivity boost when those features are available. And snippets.

    Other than that, I can see the argument for making the other parts separate extensions.
  • jmg wrote: »
    Heater. wrote: »
    4) I don't recommend using any command line compilers or loaders for Spin.

    The thing about item 4) is that we can compile the C++ source of OpenSpin into Javascript with Emscripten. The resulting JS Spin compiler can be run as a "Language Server" to get the Spin compiled into binaries.

    Nice ideal, but care is needed - take a look at those startup times on a RaspPi for the various IDE.
    BIG ratios are possible, with those ever-more layers of fluff.

    If JS Spin compiler is woefully slow, it rather defeats the purpose.

    Many production environments prefer command line compilers and loaders.

    Note that Code lazily loads extensions, so startup time should not be impacted. The extension is usually loaded only after you open a file that contains a matching language.

    In the case of extensions like compilers or loaders, you could also have the extension load only after you execute a command (via command bar, menu binding, or key binding). By splitting the extensions as Heater suggested, you wouldn't actually load the compiler until you explicitly executed the "compile" command (for example).
  • Having OpenSpin as an Emscriptened Javascript 'blob' doesn't preclude it from being a command line tool. Node will be as happy to run it from the command line as a browser's V8 engine or anything else will be. Based on the other node based apps running on the Pi, OpenSpin JS speed should not be an issue.

    The vscode load times have to do with how it is written and the layers upon layers of JS it is built with. Its target machines have tons of memory and can gulp it down quickly plus as mentioned before once you are in your IDE for the day, you don't care about load times.

    When doing anything on a Pi, yu need to pay attention to your usage habits and watch what you do...memory is the bottleneck now.
  • Seairth wrote: »
    msrobots wrote: »
    Ha. Gotcha. Interested about your 'testing' and opinion.

    I am working with VS since 20+ years, so am used to the interface. It is quite consistent over the last 10 years and IMHO quite powerful.

    If you haven't used Code, it's quite different from VS.

    Actual I have not. I just follow the news, slightly interested. I assumed that 'VS Code' is the same as the 'VS Community Edition' of last year, kind of looking like the regular VS.

    Since I do use VS with Windows I do not really tested any of the multiplatform versions. Maybe I should.

    so I better shut up now,

    Enjoy!

    Mike
  • Visual Studio appears to be out of control... Used to be by Microsoft for Windows...

    I just recently installed the new full version (not "code") and it had all kinds of cross platform compile stuff in it. Looks like you can make a C# app for iOS now...

    But, I guess that wasn't enough for them, now they have this "code" thing that also runs on the major platforms.

    They're definitely trying to take over the world...

  • jmg wrote: »
    Can it access the Smart Pins ?

    Nice features: I see conditionals and in-line C, is there also an in-line ASM form?

    Yes, there's inline assembly, and it probably works better than assembly in DAT (the stuff in DAT gets assembled with the built-in assembler, whereas inline assembly is passed through to PNut). The smart pin instructions are there, but they aren't fully implemented (the assembler doesn't know about immediate destinations yet). Nor are they tested, so caveat emptor. But you can do something like:
    PRI pinsetx(d, s)
      asm
        pinsetx d,s
      endasm
    
    PUB test
      pinsetx(3, 1)
    
    and get out:
    DAT
    	org	0
    entry
    
    _test
    	mov	arg1, #3
    	pinsetx	arg1, #1
    _test_ret
    	reta
    
    arg1
    	long	0
    arg2
    	long	0
    arg3
    	long	0
    arg4
    	long	0
    result1
    	long	0
    	fit	496
    	orgh	$400
    

  • I just wish Microsoft had been a bit brave and given Visual Studio Code a different name. It's a totally different product to any old Visual Studio. This "Visual" thing reminds me of the nightmare that was Visual Source Safe. They did it with the "Edge" browser which is not "Internet Explorer".

    Come to that they should change the company name as well as it has such a bad brand recognition.


  • I've updated the repository with the v9 instruction set. I still haven't delved into the advanced extension features, so the extension still only does syntax highlighting at the moment.
  • Heater,
    Visual Studio has been a pretty strong brand name for them for over a decade now, that's likely why they went with the name. Pretty much all the devs I know that are on windows (which is most of the ones I know) use Visual Studio and have for a long time. They also generally consider it the best IDE and especially debugger (in my opinion nothing even comes close to it on debugging).

    Anyway, on topic (sort of), I am seriously considering making an extension for Visual Studio 2015 (community edition is free) for doing Spin/PASM highlighting.

  • I really like the full Visual Studio. I looked into making an extension, but couldn't figure it out.
    Wanted to get intellisense working for Spin or PASM, but didn't see how.
    Seems like wouldn't be too hard for GCC though.
  • Any chance we can get VS Code to replace SimpleIDE?
  • FireNWater,
    Any chance we can get VS Code to replace SimpleIDE?
    I had much the same thoughts. I don't see why not.

    VS Code could also replace the Prop Tool and Propeller IDE. We have a Spin compiler in Javascript working so that could be dropped into a VS code extension.
  • Martin HodgeMartin Hodge Posts: 1,241
    edited 2016-06-11 - 22:40:46
    .
  • I'm currently working on building up an extension that provides more than syntax highlighting. It's slow going, partly due to my inexperience doing things the JavaScript way, and partly due to the sparse extension documentation. Right now, I've got the boilerplate server and providers set up, but now I need to actually add some meat to them. To that end...
    Heater. wrote: »
    We have a Spin compiler in Javascript working so that could be dropped into a VS code extension.

    This would be a mighty handy starting point, I think. I'm sure you've mentioned this before, but what is this compiler's name and is it open source?



    Note that, for now, I am limiting myself to P2 assembly language. Once I get it working well for that, I'll get P1 Spin/Asm support added.
Sign In or Register to comment.