how to embed compiler and interpreters to a website like codecademy? [closed] - javascript

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I got a project to design a website which has a javascript & HTML interpreters, Database, C++ compiler. I have searched related websites and I ended searching with codecademy
. Now I'm thinking to build something like codecademy website with my own features and functionality. Although I know how to create a dynamic website but I don't know how to embed interpreters, compilers and all. Please guys help me to build this project and successfully run

In very simplified terms, there are two ways to achieve a live interpreter/compiler on a web site:
Find (or write) a compiler/interpreter for your language that is written in Javascript
Create a (native) CGI application and run it on your server that will run a given piece of code through a (native) interpreter/compiler (also on your server) and return the result of the run. Then write a web page that calls on that CGI to do the work, usually using AJAXy Javascript things like xmlHttpRequest, or at least a web form.
That's what all of these sites essentially boil down to. Some just have an interpreter or CGI that can remember state between calls, and can then show you intermediate steps. This could be because your JavaScript-based interpreter supports pausing, or your CGI could e.g. have the program run in lldb and then your page sends certain commands to LLDB and returns information.
Note: If your question was more about how to actually write an interpreter in JavaScript, I detail the basics of parts of an interpreter here: http://orangejuiceliberationfront.com/how-to-write-a-compiler/ It is for C programmers, but the basics hold true in any programming language. You can always use arrays instead of memory blocks, and array indexes instead of memory addresses.

Simply web application takes our code as input and store in file with respective the programming language extension like .java, .c etc and then they used the server side install compiler to run the code and forward the output to the client through web page.
Suppose in java, there is class Runtime and Process with the help of this class we get the control on server side install software like java, javac etc with that we run the program and transfer the output to User..
It is very simple if any one want code for that then ping me..

Related

Why is JS interpreted and not compiled? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I've read a lot of things about interpretation, compilation, just-in-time compilation, etc. But I haven't found a clear explanation about why JS was created as an interpreted language and why there is still no ability to compile js code.
I have some thoughts, but I'm not sure about any of them:
If the browser could execute (or just pass to OS) a binary code it would be a big vulnerability because any command could be injected into a binary code (e.g. delete all files from the file system). If it's true is it possible to teach the browser to validate somehow a binary code? And it's not a problem for a back-end side. Then, why NodeJS can't execute compiled JS (the same for PHP, Python, why they are interpreted)?
Optimization isn't possible for binary code. Is it really true? Is optimized interpreted js faster than compiled (to binary) js?
Different CPUs (architectures) need different binary codes. That means it's impossible to generate a universal binary code for any client. That's why WebAssembly modules use some intermediate code? And again why to not use compiled code for a back-end?
If anyone could explain some of the above or any other reasons I would be very grateful.
Let's first say that unless you were in the design discussions for Javascript in its early days, none of us actually "know" why. The best we can do is try to infer why certain choices might have been made given the objectives they had and the choices they had.
If you look at the requirements for the original design of Javascript in web pages, you see things like this:
Must run on lots of platforms.
Must be easily embeddable in HTML pages.
Must be simple to program.
Is not initially an environment that feels the need to maximize execution performance.
Not Java.
Let's look at these...
About #1, OK, run on lots of platforms means it cannot be compiled to native machine code - period. It could be compiled to a universal byte code like Java or webAssembly, but read on about the other requirements.
About #2, it wants to be embeddable in web pages so you can do things like:
<div onclick='alert("hi")'>Click me</div>
Then, it's pretty hard to have code that is compiled in advance fit in there. You'd probably have to compile your whole web page. That creates an entirely new paradigm and browser (that expects pre-compiled code and HTML). While the world could have eventually gone there, that certainly wasn't an easy way to go (requiring a redo of the browser).
About #3, "simple to program", it's generally believed that interpreted "scripts" are simpler for people to start with than languages that need a programming environment and compiler set up and some build tools. It's faster and simpler to do simple things.
About #4, "performance". In the early days of Javascript, it was an auxiliary language to help add some client-side logic to web pages. The initial target was far simpler than what Javascript is being used for today. I rather doubt it was envisioned that a pre-compiled language was needed for what its initial target was. So, keep it simple and go with the simpler way of reaching your target.
About #5: "not Java". Java was a known tool of the day. But, Java was not super simple, required pre-compiling, had IP encumbrances, etc... So, Javascript was born to be something that was familiar to both C and Java developers, but was far simpler for someone new to pick up. Easy to do simple things.
As for environments like nodejs, they could more practically have a pre-compile step, but the early designers of nodejs decided to use the open source V8 Javascript engine rather than make their own Javascript engine. Plus, in a server world, your code is generally loaded once at server startup where V8 compiles it to a combination of native code and byte code anyway so requiring developers to pre-compile it doesn't necessarily buy you a lot anyway. This is where it matters that Javascript is now actually compiled, it's just compiled upon loading rather than requiring pre-compiling by the developer.
And, nowadays, if you want the benefits of type checking in a pre-compile step, you can use TypeScript and precompile that to Javascript.

Can any user read the coding as they're .js plain text files? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm a C# developer, and use XAML for user interfaces. Lately I've been wondering something regarding HTML5+JavaScript development (used in Universal Windows App development, as well as for websites). Javascript is compiled and executed at run-time on the client device. So any user can go into the folder where they're stored on computer, and see all the code in it, right?
There is no unreadable alternative for js and html5. That's why so many websites are so slow in adopting html5 video and replacing adobe flash.
But if your entire application is client side and you worry about your code being stolen you're doing something wrong. Almost any application requires serverside code that isn't accessible.
And it doesn't matter anyway, who cares about some js that makes a div draggable or moves some html around.
I dont think readable javascript code is of any value...what matters is the server side code like php or ASP which really matters in the security of the websites
And even if the developer didnt want the user to read the javascript framework.. what option does he/she have to prevent it..?none!
The client side code is indeed visible by the client. If something is available client side, then you won't need a round trip to the server to get it.
For example you could imagine a simple calculator application. You could write it client-side, in Javascript, the app can ouptut the calculations immediately. Or you could write it server-side (in wathever language you want), which means you need to ask the server for the calculation (with an ajax request probably), and wait for it to respond.
Also some things doesn't make sense on the server-side. Pretty much any action that changes the DOM, which only exists client-side, in the browser.
I wrote about this on my blog a while back, see Protecting Your Code,
as an addendum to my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition.
The short of it is that JS code it not protected, though you can make things a little more difficult with minification/uglification like many website authors do. You can also take steps by putting some of the code you care about into Windows Runtime Components written in C++ (C# can be decompiled). The only really secure solution is to have code on a server, and draw from that in an app which of course doesn't work for all cases, but is an option.
Note that some of my comments in that blog from 3 years ago might be a little dated. I believe that current Windows Store policy now allows you to load code from a remote server at run time.

Python CGI With Data Return [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm trying to accomplish the following:
Pull information from a module through Python. [Accomplished]
Constantly pull information from Python for use in HTML.
Avoid writing the entire HTML/CSS/JS document in print statements.
I've seen the term CGI thrown around, but don't really understand how it works. Simply put, I want to run the Python script which returns an integer value. I then would like to take that integer value into JavaScript so that it may update the designated tag. It should be able to execute the Python script every two seconds, receive the output, then apply it to the page. I do not want to write out the entire HTML document in Python by doing one line at a time, as I've seen some people doing on sites I've found.
It seems like doing something like this is far more complicated than it should be. The page should run, call the script for its output, then give me the output to use.
Well if you don't know what CGI is and find that what you ask for is "far more complicated than it should be", you first have to learn the HTTP protocol, obviously, and that's way to broad for a SO answer.
Basically what you want requires:
an html document
some javascript code, either linked from the document or embedded into it
a web server to serve the document (and the javascript)
a web server (can of course be the same as the previous one) that knows how to invoke your python script and return the result as an HTTP response (you'll probably want a json content type) - this can be done with plain CGI or with a wsgi or fcgi connector, in your case CGI might well be enough.
Then in the browser your javascript code will have to issue a GET request (ajax) every x seconds to the web server hosting the Python script and update the DOM accordingly.
This is all ordinary web programming, and as I said, a basic understanding of the HTTP protocol is the starting point.
Trying to write anything from scratch, if you don't know anything about the subject, is always going to be complicated.
That is why there is a whole world of tools to help you. I don't think you want CGI at all; look into one of the Python micro frameworks, in particular Flask. The tutorial there should give you the introduction you need.

Embed basic python game into web? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I wrote a basic python 2.7 game using things like print, for, if, else, etc. I also made a website to hold the game downloads. I was wondering if there is a way to embed the python game directly into the HTML5 website. All of the other questions that I looked at contained links to non-existant websites.
Depends on what you want and how the game does I/O, but I'd check out pypy.js, it's a version of pypy running in the browser, capable of basic I/O and what not, that would require a minimal amount of reworking your current setup. For faster loading, you could use the same toolchain as pypy.js to compile your python code to C, and the C to asm.js. That would require reworking your code to valid RPython, which requires runtime variables to be statically typed and a few other restrictions. It would allow your game to run in the console at near native speed.
If you want the game code running on a web server, a COMET/AJAX solution is the way to go. I usually use Athena LivePage from the Nevow for that type of thing. A 'drop-in' solution would be to use something like ShellInABox or PyInABox to run a server-side shell, and the run your python script inside the shell, running as a no-permissions user inside a chroot.
As I said, I'm not familiar with javascript (I have some experience in java though), but here's what I see you would have to do: Redirect print to a separate file, not sys.stdout, send to an output stream, and have javascript display the information received in the stream in the browser.
About javascript, I'm not entirely sure.
But here is a little guidance for your python code:
print "Hi! I'm Zin"
to...
print >> (destination file), "Hi! I'm Zin"
print >> sys.stderr, "Hi I'm Zin" # Will print to Python's built in error stream.

javascript hiding eval [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a method I'm testing right now for hiding javascript so that the user can't go around searching for it in the source files.
The method is this:
You have a bunch of javascript files included to make your application work. Libraries like jQuery, dojo, and your own code. This is pretty standard.
There is one critical piece of javascript code without which the app will not function, nor will any curious user be able to make heads or tails of the app without it. This critical piece does not get loaded by script tags. Instead, a small unobtrusive script calls to a database and returns the javascript in a big long string.
This string gets eval()-ed to make it live code. But the code was dynamically generated, so it won't show up if the user is looking through the source code or saves the website. Furthermore, you can add some kind of a salt or time-stamp to prevent users from trying to trick the database into revealing your javascript kernel.
I'm trying to get feedback on this from the community, and most of the examples I've turned up for hiding javascript with server-side code has just been people wanting to to include a .php file in the tags instead of .js. This is totally different.
So there you have it. Is this a good idea? What are the weaknesses?
eval() is generally frowned upon, but regardless, the big weakness is that I can simply sniff the HTTP requests and get your script. Obfuscation can make this more inconvenient, but with a good debugger its not that hard to follow a stack trace and get a good idea of what is occurring.
Even if the resource is transferred over SSL, it can be perused/manipulated once it has been loaded by the browser. To test this, I went to a secure website and examined a raw TCP response (both synchronous and asynchronous using XML HTTP) using SmartSniff. As expected, it's encrypted and unreadable. However, the same requests are all visible as plain text in Chrome's network activity inspector.
It's trivial to make Javascript code unreadable by humans (and even highly resistant to reverse engineering) - and you don't need to hide it in a of of other code. But why? Generically, the name given to this kind of code is malware.

Categories

Resources