Web-based IDE for Monkey-X
Monkey Forums/Monkey Programming/Web-based IDE for Monkey-X
| ||
| Any idea if there is such a thing? I've got myself a ChromeOS laptop and was hoping to use it for dev work when using it :) Obviously HTML5 target only is all I am wanting really. |
| ||
| Nope, but that would be pretty cool. You'd have to figure out some way of running a web based IDE and remote server on a Win/Mac/Linux box that could run the Monkey compiler tools remotely, then show the resulting HTML5 game. Something like this: https://ideone.com/ |
| ||
| I started and builded "transcc" with emscripten, with that i was able to build HTML5 Apps over the browser :) But my idea was, to connect Dropbox, but its to slow over HTTP Request, so i freezed the project sorry :/ |
| ||
| Did nobody see what I did? Really? I'll admit, I did just sort of let it fall off the face of the earth. I ported TransCC (Monkey's compiler) to JavaScript leveraging its JS translation capabilities. It's Monkey, but in your browser. For local files, that's a bit trickier, but totally doable. With that in mind, there's no IDE / good text editor. That's the real issue, but the backend is done already. Excluding network overhead, the compilation process is very quick in Chrome and Firefox. I've looked at Ace so far, but I can't use it without putting in some work. I'd need to fix the regular expression in the TextMate/Sublime language files, made by the community. |
| ||
| @SKNG WebCC is cool indeed! Would be nice if we could have it codepen.io style, with the various screen layout options. |
| ||
| @ImmutableOctect -- try ACE.js. It's easy to use and worked well for my attempt where I had the compiler running on a remote Linux server: http://www.hi-toro.com/monkeypop/ Please note: this won't run any code as the remote server is no longer running! You will get a 'TV static' screen if you attempt to run the code, though -- that's a pre-built Monkey app. Might be slow on a phone as it downloads 1MB+ of images... I really wanted it running in JS, though, like you've done! (Also, I saw it -- replied on the Blitz forum!) |
| ||
| Ah that's amazing @ImmutableOctect. I love codepen and that type of editor would indeed be amazing, but ACE as an editor would work just fine! It would be great if more people could get involved in a webCC/web editor version of Monkey-X :) Monkey Pop! looks amazing @DruggedBunny. Any way you could provide more information on how you made it work with a remote server? |
| ||
| @DruggedBunny: Did you write the "mode" file yourself, or generate it? Or did someone else do this, and I never heard about it? The two reasons I didn't use Ace sooner were licensing (Which isn't really a problem at this point), and broken regular expression in the files it generates from TextMate's format. Assuming you don't mind, I'm seriously thinking about using this file (Or a modified version of it) in WebCC. This would help with the need for an in-browser editor. This reminds me; to everyone here: What modules should I add to my distribution of WebCC? |
| ||
| @IO: It was samowitsch who did the ace.js mode file (see link) -- regex is definitely not my thing! Pretty sure he'd be happy for it to be used, but can't obviously say for sure. I see I forgot to credit him (sorry, samowitsch, though I'd covered everyone!), but it was never made public, mainly for fear of server costs in event of hackery/DDOS, on the assumption someone would figure out the remote IP, which is why your js port is completely awesome! How do you handle things like images, by the way? I had some pre-selected images on my front-end server (the above link), so the user would be able to LoadImage any of those (and only those) using the local filename (eg. "catgirl.png"), plus copies of same on the remote server so Monkey wouldn't complain during the build process, though I only needed to return main.js to the front-end page after that. Not sure how you would load from local files in the purely js setup, so I'm curious! Do they have to be placed in a special location? EDIT: samowitsch's ace.js was on Github, going by that thread, so would be distributable one way or another -- seems to have gone now, though. EDIT 2: This appears to be samowitsch's Github copy of ace, renamed by me at some point, mainly just uploaded as it contains the LICENSE file, but I think the slightly-tweaked files on monkeypop will be the latest: http://www.hi-toro.com/monkeypop/ace-monkey.7z |
| ||
| @DruggedBunny: Thank you, I'll be sure to set up Ace, and see how that goes. I don't have as much free time, but I'll definitely work on this. On to the explanation: I essentially built a fully functional file-system. It asks for files only if they're not available locally. So, if it's not there locally, and the server's not coming back with anything, the file doesn't exist. I did some other work on things like folder behavior, but that's the gist of it. For custom resources and source files, I simply modified the target and Mojo implementation. Instead of using 'XMLHttpRequest' objects, or using DOM's 'src' properties, it has the browser generate a URI for the file, making it a tangible resource. This URI layer mainly applies to things like images and sounds (Untested; should work from what I remember). For normal loading of data, the target's methods are modified to simply retrieve the file's contents in the correct format. Finally, you have 'LoadString', which will take the file's content, and convert as needed. The current format is string-based, but the 'regal.virtualos' module supports several storage techniques (Strings, Base64, 'ArrayBuffers', etc). Things related to configuration across multiple uses are stored with specific symbols, but are effectively just map/dictionary entries, which are properties in JavaScript. As for giving files to the file-system, you press an invisible button (CSS trick) behind the + graphic, and that gives you the right to read the file the user picks. I then take the extension of the file, and use that to sort where it goes. So, "monkey" files go to a specific folder where your main file lives, and other resources go to its "data" folder. This is all done by reading the entire file into the file-system, similar to how things are downloaded from a server when there's no local entry. Now, add file-version management and response caching, and you have a functional build environment. Overall, it's not perfect, but it works really well. Unfortunately, unless I later pre-fetch the remote file-system, the compiler does stall the tab while it's working. This would normally be fine, but on some servers, HTTP requests are slower (DropBox for example). Sadly, this is a synchronous compiler that requires ordered loads, so you can't download in parallel, either. This is why pre-fetching files (Modules) is probably what I'll end up doing. It wouldn't take much work, and it'd improve the experience. This is likely going to be an option later down the road. The other details are mostly in the article I wrote, but I imagine you read that beforehand. |
| ||
| Oopsie, thanks for the write-up! Pretty immense piece of work... I think the local caching of modules would be a good idea -- it's really what my front-end did with the images. (Took me a while to realise I could do this instead of sending the whole project back!) I did see your article when first posted, but didn't have time to read it then. Might have a go at getting it running myself, so will give it a proper read! |
   |