If I recall correctly, dgately has created an iOS version of openspin. I'm not sure if the same can be done for Android - anyone know?
Heater,
I had held-off on testing a compile/build of openspin on Android as I assume that your JavaScript-via-emscripten would probably just work on that platform. I don't think there's much of a problem getting openspin in some form on the Android platform. I have balked a bit on my own effort with Android also because I'm concentrating on Bluetooth LE for the moment and A) I don't have a Bluetooth LE supported Android tablet and Android support for Bluetooth LE has been a very recent addition (Android 4.3 or 4.4 are required)...
Now things are getting usable. The Editor supports multiple files now. Not really tabs, but close.
Still work in progress:
- the autocomplete needs more work
- you can not close Editor Tabs yet. Just reuse.
- the cmd-line interface (Browser parameter...) can just open editor with one file - more would be nice to setup a whole session with one link.
Now to the compiler integration. Since I can now open new editor tabs I can pretty easy call external tools per XMLhttp and return the result in a new Editor tab.
This could work for @jazzed solution and @heaters solution as well.
@jazzed other way is pretty interesting, But requires a server connected to the propeller boards to use serverside usb ports and run the compilers. May run nice for class rooms.
@Heaters version runs in the browser. And does not need a dedicated server for compiling. Done in the browser. Would work for me and the spinneret. If I could get it running on W8.1 and Chrome. No dice yet. I still need to grook Mr. Philgrims auto complete for spin to integrate into the Editor and - well - am on my way to learn that astonishing language JavaScript again. Funny how it evolved. So emscripten(?) has to wait until I understand more of it. This is bugging me because I really need openspin running from the spinneret. Even if just for one spin file. fine with me. I need to compile PASM blobs (coglets?)
While testing the Editor I activated cross-origin access on one of my webservers in Europe. It is one of my test-servers. I host a small site there to have a copy of the spinneret svn hosted at google code. Googl code does not allow html file to be shown in the browser, but since the spinneret doc is htm based I needed some place to store them for viewing.
In this case it is a W2003 server, but what you need to do will work on any webserver.
I am not talking about write access here, just read access for cross origin requests. To do that you will need to add a header for those directories and files you would like to share.
Access-Control-Allow-Origin: *
Will allow the editor to access files using JavaScript in the browser from some other origin as the files are. If you have the Editor on the same server as the files to open it is NOT needed to add this header.
Anyways - works nicely. Even if you just save the Editor to your local file system and start it from there in your browser, you will be able to edit (but not save) all files below this URL. http://parallax.msrobots.net/propeller-w5200-driver/
This is a quite nice way to store Libraries in the www.
I was thinking. Why not forget those stupid old fashioned ideas about tabs.
I'm thinking big colourful icons as buttons. That represent objects in Spin. A little TV for a TV driver. A 9 pin D-type plug for a serial driver and so on.
Of course ultimately these objects would be browsable from a web repo and drag-n-dropable into your project. One would have to be able to add ones own objects of course.
By now I just add a button to the div. could be a image as well.
I use the button.title property as filename.
look at the source.
Of course you have to start at the end of the source file and scroll backwards. You are English, so you should understand The most useful stuff is at the end of the file.
Then you will see how stupid simple the editor is.
all included files of CodeMirror3 are unchanged.
please give me an update on your work on openspin in javaScript .
can you give me a current ZIP pretty please? Just for those lost windows users out there?
I really would like to run those compilers in a browser....
You bet I've already been peeking at the source. I wanted to see what those buttons did so I could get upload/download working from the node.js server.
Being English I do like "stupid simple". Well, I barely understand how all this web technology hangs together anyway.
The last almost working compiler was openspin_web_demo3.zip posted a while back. That works but will eventually blow up on Chrome. FireFox seems OK.
I think my next effort for openspin on the web will be to wrap it up as a web worker process. Then it can be started, compile once and then totally destroyed! Surely that cannot leak anything.
One of the important configurations is to have all tools hosted by a PC (or RPi) and have a Propeller board like the ActivityBot network enabled with a Wifi module like the Digi S6B. I was assuming we must follow the Same Origin Policy and have separate browser windows for editor/compiler and loader/terminal. Well, I've been working with David Betz on communicating with the S6B, and we have figured out how to use Cross Origin Resource Sharing CORS so that a single browser window can do everything. The webtool prototype will be updated to use CORS in time.
Kudos to David Betz for putting together the PropellerGCC xbee-loader demo that allows using CORS. The end goal of xbee-loader is to load and run propeller programs over Digi's S6B XBee Wifi module (there is more work to do before it is ready).
Any chance you could post a version of your EditorXX.html which is actually a package of the CodeMirror editor and other JS components separated out into their own .js files alnog with the minimal HTML/JS for the page?
The last almost working compiler was openspin_web_demo3.zip posted a while back. That works but will eventually blow up on Chrome. FireFox seems OK.
I think my next effort for openspin on the web will be to wrap it up as a web worker process. Then it can be started, compile once and then totally destroyed! Surely that cannot leak anything.
@Heater,
We would like to use openspin_web with Chrome for testing on ChromeOS and/or ChromiumOS.
ChromiumOS is the open source variant of the Chromebook ChromeOS. ChromeOS can be used in virtualbox.
Chrome Apps are written in HTML5, JavaScript, and CSS.
Chrome Apps have access to Chrome APIs and services not available to traditional web sites.
Use the chrome.serial API to read from and write to a device connected to a serial port.
Turns out this all works on the Googl Chrome browser, no Chrome book required!
Heater, that IP address is on my local network. If you had a similar configuration on your network, the IP address of your board would be used. I did make a brief attempt last night to configure my router so anyone could enter my public IP address to access the bot. I may do it for a CAM bot later.
Looking at the packets coming from iPAD ... it looks like the body of the packet is dropped. As David mentioned to me, we may need hardware flow control to preserve all packet contents. Meanwhile, I can move the command sequences to the first HTTP request field which makes parsing much easier.
I love the idea of the entire forum hammering on you poor bot over the net. (Err..that does not sound quite right now does it?)
Whilst I got that Chrome serial app demo to run it does not see my USB/serial adapter. The console is complaining about use of unused methods in the serial API. Seems they have overhauled the API and that code no longer works. Grrr...
Any chance you could post a version of your EditorXX.html which is actually a package of the CodeMirror editor and other JS components separated out into their own .js files alnog with the minimal HTML/JS for the page?
I also have integrated OpenSpin into the editor, hitting compile opens a new Tab showing the output of the compiler and allowing to save the resulting binary.
I had to change the way OpenSpin returns the resulting binary file so small changes where needed to OpenSpin.js (see end of the file).
Funny thing is that it now works with Chrome and IE ...
no new file yet ... I need to remove some debug windows and stuff like that.
I also have integrated OpenSpin into the editor, hitting compile opens a new Tab showing the output of the compiler and allowing to save the resulting binary.
I had to change the way OpenSpin returns the resulting binary file so small changes where needed to OpenSpin.js (see end of the file).
Funny thing is that it now works with Chrome and IE ...
no new file yet ... I need to remove some debug windows and stuff like that.
will give a update soon.
Enjoy!
Mike
What did you need to add to your Spinneret server to support CORS? Maybe we're missing something.
I also have integrated OpenSpin into the editor, hitting compile opens a new Tab showing the output of the compiler and allowing to save the resulting binary.
I had to change the way OpenSpin returns the resulting binary file so small changes where needed to OpenSpin.js (see end of the file).
Funny thing is that it now works with Chrome and IE ...
no new file yet ... I need to remove some debug windows and stuff like that.
I also have integrated OpenSpin into the editor, hitting compile opens a new Tab showing the output of the compiler and allowing to save the resulting binary.
I had to change the way OpenSpin returns the resulting binary file so small changes where needed to OpenSpin.js (see end of the file).
Funny thing is that it now works with Chrome and IE ...
no new file yet ... I need to remove some debug windows and stuff like that.
will give a update soon.
Enjoy!
Mike
What kind of low-level interface does your web server need for talking to the hardware? How hard would it be to get it to talk to the Xbee WiFi module instead of the WizNet chip?
What did you need to add to your Spinneret server to support CORS? Maybe we're missing something.
CORS is quite simple if you leave all the BS out.
JavaScript XMLhttprequests are just allowed on the same server/domain/subweb/port/whatever the page they are started in is loaded from. Else it is considered as a Cross Origin Request. And will be blocked for security reasons.
To allow Cross Origin Requests the webserver DELIVERING the files on a GET request (or accepting PUT etc.) has to add a Header to the response ALLOWING Cross Origin Requests.
Simple like that. It is up to the server allowing it or not. As stated a couple of times here in that thread this is done by adding a HEADER to the response of the server stating:
Access-Control-Allow-Origin: *
And anybody can now request the file. Not just in the browser but ALSO out of JavaScript with XMLhttprequest. That's it. No further magic needed.
Uuups. I need to update the google code repo. Gimme some hours ... I need to tidy things up and recreate the Spin Doc htm files with Phil's Spin Documenter....
But to make things clear:
My version of the spinneret firmware is a direct adaption of Mike Gebhards work on the spinneret. Mike forked a directory for me at google code and I am working on it as time allows me. It uses WizNets W5100 chip/driver. But thanks to Mike G it will be easy to move this to W5200 (a Module Parallax sells) and the new yet to come Spinneret 2.0 with W5800? chip.
But having a propeller doing DHCP-client, DNS-client, NetBIOS Name Service and SD file system combined with a webserver serving static files and dynamic pasm pages leaves not much propeller left. (by now exactly 206 longs for stack).
So adapting it to the WizNet Module will not work.
If I am able to get some more spin space free I might be able to get loading another propeller working. Then we have some sort of IDE (with PropPlug...) running on the spinneret.
I hadn't had time to inspect your JavaScript terminal. But this MAY be nice to implement too. I already have 4portserial integrated to the spinneret.
@Heater
just for the fun. Can you maybe create some other compilers in JS running? I am fine with OpenSpin, It does what I need, but how about Xbasic, PropBasic, Catalina?, PropGcc?
I haven't had time to look at that emscripten thing, But CodeMirror has syntax highlighting for Spin, C and C++ now. And I do have examples for VBscript and VB.net. So basic BASIC highlighting should be possible too...
...just for the fun. Can you maybe create some other compilers in JS running? I am fine with OpenSpin, It does what I need, but how about Xbasic, PropBasic, Catalina?, PropGcc?
Sorry to be a party pooper but I have to say no to that request.
I barely have time to tinker with openspin.js as it is. Catalina an GCC are huge, complex and have lots of parts and need a whole file system full of support files. I don't think I want to go there ever. BASICs don't really float my boat but perhaps in the future. For fun.
What I was hoping to do was document all the little steps taken to build openspin with emscripten so that others don't have to search around and experiment so hard if they want to tackle other such programs. Perhaps I should finish documenting how that demo3 was configured and built evn if it is not quite working as we want.
OK. - @Heater. - why not working as we want? - AFAIK it works pretty well. Tried it with Chrome and IE11...
here now a Version 5 of the editor. This time I added OpenSpin.js. Since the file is to big to reasonable include it into the Editor.htm I left it as external file. Thus a editor.zip as attachment.
Now you can load(GET) a spin file, edit it, save (PUT) the source file again, compile with OpenSpin and save (PUT) the resulting binary file.
If your spin source file is referencing other spin objects you need to have them open in a editor tab as well. Seems to choke on objects included multiple times in different objects.need to test this more.
When I use openspin.js under Chrome on my Debian it consumes 64MB of RAM each to you run it which is never released. Eventually the Chorme web page process dies. This did not seem anything like so bad under FireFox although I still have my suspicions.
What OS hare you using? I would have guessed it world be the same.
Ideally we should run processes like tins in a web worker so that the browser GUI is not locker up whilst they are running. It's not such a big deal with
compiling small Spin programs but still.
Hope I can get time to check put Editor5 tomorrow.
Seems to choke on objects included multiple times in different objects.need to test this more.
Thinks, thinks...
I think there must be some issues with openspin.js (demo3 was it). It does not reinitialize all the global variables that openspin uses so if you run it twice
things get a bit weird.
Is there any way we can rely on getting files from a client folder or at worse a remote server?
Emescripten sets up it's own in memory file system so that it can support all the standard C library functions.
That FS can be populated with whatever you like prior to running openspin.js.
The binary file is written back to that FS.
So, one should be able to get the files from anywhere and dump them into emscriptens FS, do the compile, and fetch the binary out.
It's not necessary to have all the files open in edit windows.
Emescripten sets up it's own in memory file system so that it can support all the standard C library functions.
That FS can be populated with whatever you like prior to running openspin.js.
The binary file is written back to that FS.
So, one should be able to get the files from anywhere and dump them into emscriptens FS, do the compile, and fetch the binary out.
It's not necessary to have all the files open in edit windows.
Yes - it is like that. But since I do not have a parser to look for the needed files I simply decided to copy all open spin files to the FS to allow OpenSpin.js to find at least those open files.
I went carefully thru the OpenSpin.js file and found references to reading files with XMLhttprequests - BUT - I am still to stupid to understand how to archive that. MAY be a config thing while compiling with emscripten?.
I did run the editor/compiler from the Spinneret and OpenSpin does NOT try to request a file with XMLhttprequest if it is not found in the FS.It just errors out. If it would do that, things MAY be easier.
Of course you can manually upload all files possible needed to the FS of the browser, but that seems sort of wasteful.
I do currently run this in Win 8.1 with Chrome or IE11. Both work, both compile, both get the same error Messages, if there are any, so it seems to work well.
Not sure about the memory leak. I did change the way to return the binary (see end of .js file) to use the ModuleConf object to transfer filename of needed binary file and content of it back. This takes care of those closures and since I return the binary as a typed array it is supposed to be self contained and not just a reference. This MAY fix the Memory problem since the GC can destroy the closure.
I can run the compiler multiple times without issue. And the FS seems to be empty on every new start - sound good to me.
I went carefully thru the OpenSpin.js source generated with emscripten by @Heater. Not easy to understand anything of it. But it looks like it is behaving different, depending on where it is run at. So there is support for Node, Web, WebWorker and other options inside the same file.
I will look at this WebWorker stuff next.
BTW - you do not need to save a file before compiling - it will use the content of the editor. So just type something in there, give it a .spin filename and hit compile.
Comments
Heater,
I had held-off on testing a compile/build of openspin on Android as I assume that your JavaScript-via-emscripten would probably just work on that platform. I don't think there's much of a problem getting openspin in some form on the Android platform. I have balked a bit on my own effort with Android also because I'm concentrating on Bluetooth LE for the moment and A) I don't have a Bluetooth LE supported Android tablet and Android support for Bluetooth LE has been a very recent addition (Android 4.3 or 4.4 are required)...
dgately
Now things are getting usable. The Editor supports multiple files now. Not really tabs, but close.
Still work in progress:
- the autocomplete needs more work
- you can not close Editor Tabs yet. Just reuse.
- the cmd-line interface (Browser parameter...) can just open editor with one file - more would be nice to setup a whole session with one link.
Now to the compiler integration. Since I can now open new editor tabs I can pretty easy call external tools per XMLhttp and return the result in a new Editor tab.
This could work for @jazzed solution and @heaters solution as well.
@jazzed other way is pretty interesting, But requires a server connected to the propeller boards to use serverside usb ports and run the compilers. May run nice for class rooms.
@Heaters version runs in the browser. And does not need a dedicated server for compiling. Done in the browser. Would work for me and the spinneret. If I could get it running on W8.1 and Chrome. No dice yet. I still need to grook Mr. Philgrims auto complete for spin to integrate into the Editor and - well - am on my way to learn that astonishing language JavaScript again. Funny how it evolved. So emscripten(?) has to wait until I understand more of it. This is bugging me because I really need openspin running from the spinneret. Even if just for one spin file. fine with me. I need to compile PASM blobs (coglets?)
While testing the Editor I activated cross-origin access on one of my webservers in Europe. It is one of my test-servers. I host a small site there to have a copy of the spinneret svn hosted at google code. Googl code does not allow html file to be shown in the browser, but since the spinneret doc is htm based I needed some place to store them for viewing.
In this case it is a W2003 server, but what you need to do will work on any webserver.
I am not talking about write access here, just read access for cross origin requests. To do that you will need to add a header for those directories and files you would like to share.
Access-Control-Allow-Origin: *
Will allow the editor to access files using JavaScript in the browser from some other origin as the files are. If you have the Editor on the same server as the files to open it is NOT needed to add this header.
Anyways - works nicely. Even if you just save the Editor to your local file system and start it from there in your browser, you will be able to edit (but not save) all files below this URL. http://parallax.msrobots.net/propeller-w5200-driver/
This is a quite nice way to store Libraries in the www.
As usual rename Editor4.htm.txt to Editor4.htm
So.
Enjoy!
Mike
Cool, Works a treat.
I was thinking. Why not forget those stupid old fashioned ideas about tabs.
I'm thinking big colourful icons as buttons. That represent objects in Spin. A little TV for a TV driver. A 9 pin D-type plug for a serial driver and so on.
Of course ultimately these objects would be browsable from a web repo and drag-n-dropable into your project. One would have to be able to add ones own objects of course.
By now I just add a button to the div. could be a image as well.
I use the button.title property as filename.
look at the source.
Of course you have to start at the end of the source file and scroll backwards. You are English, so you should understand The most useful stuff is at the end of the file.
Then you will see how stupid simple the editor is.
all included files of CodeMirror3 are unchanged.
please give me an update on your work on openspin in javaScript .
can you give me a current ZIP pretty please? Just for those lost windows users out there?
I really would like to run those compilers in a browser....
Enjoy!
Mike
Here is a funny thing.
I just served up Editor4.html from that JavaScript server I posted a little while back.
The load button works fine. The save will need some server tweaking.
But hitting "Load" with no file name in the text box causes it to load the Editor4.html file itself into the editor!
You bet I've already been peeking at the source. I wanted to see what those buttons did so I could get upload/download working from the node.js server.
Being English I do like "stupid simple". Well, I barely understand how all this web technology hangs together anyway.
The last almost working compiler was openspin_web_demo3.zip posted a while back. That works but will eventually blow up on Chrome. FireFox seems OK.
I think my next effort for openspin on the web will be to wrap it up as a web worker process. Then it can be started, compile once and then totally destroyed! Surely that cannot leak anything.
Kudos to David Betz for putting together the PropellerGCC xbee-loader demo that allows using CORS. The end goal of xbee-loader is to load and run propeller programs over Digi's S6B XBee Wifi module (there is more work to do before it is ready).
Interesting stuff re: CORS.
msrobots.
Any chance you could post a version of your EditorXX.html which is actually a package of the CodeMirror editor and other JS components separated out into their own .js files alnog with the minimal HTML/JS for the page?
@Heater,
We would like to use openspin_web with Chrome for testing on ChromeOS and/or ChromiumOS.
ChromiumOS is the open source variant of the Chromebook ChromeOS. ChromeOS can be used in virtualbox.
I have been contemplating picking a Samsung Chrome book for a while now. You might just be pushing me over the edge:)
I'll have to see what 'er indoors thinks about it.
Anyone here have any actual experience of using a ChromeBook?
I'm not sure how exactly this will work. My guess is that a web-server needs to host the app.
If HTML5 does allow access to USB serial ports, that helps for programming.
As for propeller Wifi stuff, that's up in the air right now.
Chrome Apps are written in HTML5, JavaScript, and CSS.
Chrome Apps have access to Chrome APIs and services not available to traditional web sites.
Use the chrome.serial API to read from and write to a device connected to a serial port.
Turns out this all works on the Googl Chrome browser, no Chrome book required!
Here is how to get started: http://developer.chrome.com/apps/first_app.html
Here is a bunch "hello worlds" https://github.com/GoogleChrome/chrome-app-samples
Includes examples of using the serial port!
I just managed to get hello world and serial control demos to work!
Also, I'm having trouble keeping this a secret ....
My Wifi ActivityBot responds to this googlecode page ! Android Chrome, Chrome or my ChromeOS VM.
The Digi S6B Wifi server was written mostly by David Betz ... I just added some commands.
Unfortunately, Firefox and Internet Exploder are not supported yet. Safari on my Mac works, but only the HELLO button works on my iPAD.
The arrows don't do anything yet, but clicking on the tiny little LEDs by the bread-board controls the LED on/off in Chrome.
Anyone with a Digi S6B Wifi module, an ActivityBoard/ActivityBot, and PropellerGCC can run the demo. Reply here for more info ....
Again, sadly I can't see your 192.168.1.103 from here !
Congrats!
-Tor
Heater, that IP address is on my local network. If you had a similar configuration on your network, the IP address of your board would be used. I did make a brief attempt last night to configure my router so anyone could enter my public IP address to access the bot. I may do it for a CAM bot later.
Looking at the packets coming from iPAD ... it looks like the body of the packet is dropped. As David mentioned to me, we may need hardware flow control to preserve all packet contents. Meanwhile, I can move the command sequences to the first HTTP request field which makes parsing much easier.
I love the idea of the entire forum hammering on you poor bot over the net. (Err..that does not sound quite right now does it?)
Whilst I got that Chrome serial app demo to run it does not see my USB/serial adapter. The console is complaining about use of unused methods in the serial API. Seems they have overhauled the API and that code no longer works. Grrr...
Yes to both. My spinneret server supports CORS for read and write and one of my webservers ( http://parallax.msrobots.net/propeller-w5200-driver/) does CORS for read also.
So you can for example copy this URL http://parallax.msrobots.net/propeller-w5200-driver/Spinneret-msrobots/Dhcp.spin and open the file in the editor.
I also have integrated OpenSpin into the editor, hitting compile opens a new Tab showing the output of the compiler and allowing to save the resulting binary.
I had to change the way OpenSpin returns the resulting binary file so small changes where needed to OpenSpin.js (see end of the file).
Funny thing is that it now works with Chrome and IE ...
no new file yet ... I need to remove some debug windows and stuff like that.
will give a update soon.
Enjoy!
Mike
Sound's like you're making good progress.
CORS is quite simple if you leave all the BS out.
JavaScript XMLhttprequests are just allowed on the same server/domain/subweb/port/whatever the page they are started in is loaded from. Else it is considered as a Cross Origin Request. And will be blocked for security reasons.
To allow Cross Origin Requests the webserver DELIVERING the files on a GET request (or accepting PUT etc.) has to add a Header to the response ALLOWING Cross Origin Requests.
Simple like that. It is up to the server allowing it or not. As stated a couple of times here in that thread this is done by adding a HEADER to the response of the server stating:
Access-Control-Allow-Origin: *
And anybody can now request the file. Not just in the browser but ALSO out of JavaScript with XMLhttprequest. That's it. No further magic needed.
Uuups. I need to update the google code repo. Gimme some hours ... I need to tidy things up and recreate the Spin Doc htm files with Phil's Spin Documenter....
But to make things clear:
My version of the spinneret firmware is a direct adaption of Mike Gebhards work on the spinneret. Mike forked a directory for me at google code and I am working on it as time allows me. It uses WizNets W5100 chip/driver. But thanks to Mike G it will be easy to move this to W5200 (a Module Parallax sells) and the new yet to come Spinneret 2.0 with W5800? chip.
But having a propeller doing DHCP-client, DNS-client, NetBIOS Name Service and SD file system combined with a webserver serving static files and dynamic pasm pages leaves not much propeller left. (by now exactly 206 longs for stack).
So adapting it to the WizNet Module will not work.
If I am able to get some more spin space free I might be able to get loading another propeller working. Then we have some sort of IDE (with PropPlug...) running on the spinneret.
I hadn't had time to inspect your JavaScript terminal. But this MAY be nice to implement too. I already have 4portserial integrated to the spinneret.
@Heater
just for the fun. Can you maybe create some other compilers in JS running? I am fine with OpenSpin, It does what I need, but how about Xbasic, PropBasic, Catalina?, PropGcc?
I haven't had time to look at that emscripten thing, But CodeMirror has syntax highlighting for Spin, C and C++ now. And I do have examples for VBscript and VB.net. So basic BASIC highlighting should be possible too...
back to work...
Enjoy!
Mike
I barely have time to tinker with openspin.js as it is. Catalina an GCC are huge, complex and have lots of parts and need a whole file system full of support files. I don't think I want to go there ever. BASICs don't really float my boat but perhaps in the future. For fun.
What I was hoping to do was document all the little steps taken to build openspin with emscripten so that others don't have to search around and experiment so hard if they want to tackle other such programs. Perhaps I should finish documenting how that demo3 was configured and built evn if it is not quite working as we want.
here now a Version 5 of the editor. This time I added OpenSpin.js. Since the file is to big to reasonable include it into the Editor.htm I left it as external file. Thus a editor.zip as attachment.
Now you can load(GET) a spin file, edit it, save (PUT) the source file again, compile with OpenSpin and save (PUT) the resulting binary file.
If your spin source file is referencing other spin objects you need to have them open in a editor tab as well. Seems to choke on objects included multiple times in different objects.need to test this more.
Enjoy!
Mike
Ouch. I've been relying on a local library. Is there any way we can rely on getting files from a client folder or at worse a remote server?
What OS hare you using? I would have guessed it world be the same.
Ideally we should run processes like tins in a web worker so that the browser GUI is not locker up whilst they are running. It's not such a big deal with
compiling small Spin programs but still.
Hope I can get time to check put Editor5 tomorrow. Thinks, thinks...
I think there must be some issues with openspin.js (demo3 was it). It does not reinitialize all the global variables that openspin uses so if you run it twice
things get a bit weird.
That FS can be populated with whatever you like prior to running openspin.js.
The binary file is written back to that FS.
So, one should be able to get the files from anywhere and dump them into emscriptens FS, do the compile, and fetch the binary out.
It's not necessary to have all the files open in edit windows.
Yes - it is like that. But since I do not have a parser to look for the needed files I simply decided to copy all open spin files to the FS to allow OpenSpin.js to find at least those open files.
I went carefully thru the OpenSpin.js file and found references to reading files with XMLhttprequests - BUT - I am still to stupid to understand how to archive that. MAY be a config thing while compiling with emscripten?.
I did run the editor/compiler from the Spinneret and OpenSpin does NOT try to request a file with XMLhttprequest if it is not found in the FS.It just errors out. If it would do that, things MAY be easier.
Of course you can manually upload all files possible needed to the FS of the browser, but that seems sort of wasteful.
I do currently run this in Win 8.1 with Chrome or IE11. Both work, both compile, both get the same error Messages, if there are any, so it seems to work well.
Not sure about the memory leak. I did change the way to return the binary (see end of .js file) to use the ModuleConf object to transfer filename of needed binary file and content of it back. This takes care of those closures and since I return the binary as a typed array it is supposed to be self contained and not just a reference. This MAY fix the Memory problem since the GC can destroy the closure.
I can run the compiler multiple times without issue. And the FS seems to be empty on every new start - sound good to me.
I went carefully thru the OpenSpin.js source generated with emscripten by @Heater. Not easy to understand anything of it. But it looks like it is behaving different, depending on where it is run at. So there is support for Node, Web, WebWorker and other options inside the same file.
I will look at this WebWorker stuff next.
BTW - you do not need to save a file before compiling - it will use the content of the editor. So just type something in there, give it a .spin filename and hit compile.
Enjoy!
Mike
..