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:
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.
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!
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)
(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!
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.
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"! )
$ 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:
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
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.
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
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!!!)
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?
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.
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 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.
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:
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.
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.
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.
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...
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?
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.
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...
Comments
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. 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.
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) (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) 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!
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"! )
Match:
Baseball GAME:
Surface Pro - the Official Tablet of the NFL??
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/ 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: 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: After an age and many grumbling messages the VSC window opened on my PC !
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
Sounds like there will be lots of versions of Spin for the P2 soon
'' '' 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 0As 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.
RasPi 3 - no overclocking, Raspbian Jessie (maybe 1 release back?)
1GB of memory
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!!!)
I have to get a display hooked up to a Pi here and see how it goes.
Be glad I'm not marketing!!
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!
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?
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.
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....
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.
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.
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).
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.
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
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...
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:Come to that they should change the company name as well as it has such a bad brand recognition.
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.
Wanted to get intellisense working for Spin or PASM, but didn't see how.
Seems like wouldn't be too hard for GCC though.
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.
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.