python + other languages execution is possible! #242
Comments
AnirudhG07
changed the title
|
Not just python, we can execute more languages using that hack that you can run everything through bash. ```bash +exec
#!/bin/bash
# Run Python code
python -c """
print('Hello from Python!')
"""
# Write and run Java code
cat > HelloWorld.java << EOF
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello from Java!");
}
}
EOF
javac HelloWorld.java
java HelloWorld
# Write and run JavaScript code
cat > hello.js << EOF
console.log('Hello from JavaScript!');
EOF
node hello.js
# Write and run Rust code
cat > hello.rs << EOF
fn main() {
println!("Hello from Rust!");
}
EOF
rustc hello.rs
./hello
# Write and run Go code
cat > hello.go << EOF
package main
import "fmt"
func main() {
fmt.Println("Hello from Go!")
}
EOF
go run hello.go
# Write and run C code
cat > hello.c << EOF
#include <stdio.h>
int main() {
printf("Hello from C!\n");
return 0;
}
EOF
gcc hello.c -o hello
./hello
# Write and run C++ code
cat > hello.cpp << EOF
#include <iostream>
int main() {
std::cout << "Hello from C++!" << std::endl;
return 0;
}
EOF
g++ hello.cpp -o hello
./hello
# Write and run C# code
cat > hello.cs << EOF
using System;
class Program {
static void Main() {
Console.WriteLine("Hello from C#!");
}
}
EOF
mcs hello.cs
mono hello.exe
\```
and so on...I have tested and every single one of these work. |
|
I ll be putting up a languages.md where every language code can be executed |
|
I think ideally if this is to be supported properly, it should be via a I don't know about adding an example presentation for this, unless it's using the proper implementation ^. As I said above, this looks a bit strange so I don't want to advertise it as "multiple language execution support" unless it looks correct. I didn't bother adding this yet because nobody's asked about it and it opens a pandora's box where we would need to support potentially lots of languages and I don't know if I have the time to figure out how to execute them all and ensure it works correctly for all of them. |
|
True. |
|
But for those who want to use and show some execution of other language codes can always try this way out(like i needed python). Though not ideal. |
|
Have you considered an approach like patat? You use the front matter to register "evaluators", which each contain the command you want. Then you can reference the evaluator in the slides alongside the existing code highlighter block. This way, Any thoughts @mfontanini? |
|
I am experimenting with a couple of approaches - see dmackdev#1 for an example of one of them that uses your code snippet examples @AnirudhG07. |
|
@dmackdev I like the patat idea of having executors be part of your configuration. However, without looking too deep into how patat does this, I think that works well for interpreted languages but probably not so much for compiled ones. In the latter execution is a two step process so the What I was thinking of would be to have this in a somewhat similar way but not exactly that way. Instead of having this be a part of a presentation's front matter, we could have shell scripts per language that define how to execute it. We could have a set of builtins and let you extend them locally by dropping a file in a directory like #!/usr/bin/env bash
python $1For other ones like java you'd use On presenterm's side we'd need to:
I think this makes it:
Thoughts? This also seems to be similar to how PS: the solution you're suggesting in your branch works but is IMO a bit too involved for users. I'd prefer if the steps to get code running was defined once and everyone could benefit from it. That is, I don't think people would need/want to go through the effort of doing the |
I had the same observation too - I experimented with an executors/evaluators approach and I resorted to using cargo-script for the command in a Rust code evaluator. See here for reference. |
That may be the case, and it certainly would be a lot of repetition in the markdown for multiple code snippets. However, I wonder if the "hidden code lines that still execute" feature may still be desirable, but to serve a different use case: namely to be able to display only the main focus of the code snippet, without displaying the setup/boilerplate code. This is one of the motivations of this feature in rustdocs. This way, the code in the markdown would be complete (albeit with the delimiters), and any other script that executes the code like in your suggested approach can assume the code snippet is a valid program, whilst providing users with the ability to focus/show only the relevant lines of code. What I mean is, if I only wanted to show the Java line: System.out.println("Hello from Java!");the script that executes it should not be required to wrap it in a class and a main method in order to create a valid Java program. But presenters can still hide the enclosing class and main method to show only that line. I suppose there might be some more work involved to make sure |
I like your approach - it certainly would be easier to configure/test standalone scripts compared to trying to express them in YAML in the front matter. So is your thinking that What would also be great is if your approach could respect configurations local to the presentation file directory, so I could co-locate the presentation and the code executor script in the same repository. Or I guess you could use the |
Yes, I agree. Your solution addresses a problem that will become more evident once language execution works. And as you say, it will likely require a bunch more work.
Yes, exactly.
Yeah we can also let you override this per presentation. e.g. the config file (which can be overriden already on a per presentation basis) can have a path to where executors are. So you could override that in a presentation and point to |
|
@dmackdev I'll work on this now that you fixed the outstanding issues. Having proper stderr handling is a must now that we'll be invoking programs that may fail on purpose (e.g. "this is how the borrow checker errors when you do this in rust"). |
|
Sounds good! BTW I have created a new branch for the hidden code lines that removes any support for executing code in languages other than |
|
I just created a PR to add the groundwork for this + the python executor as a showcase. Somehow the output is being buffered so doing things like |
I gotta run now so I'll have a look later / tomorrow |
|
Alright, I merged the PR. So now we have python code execution and adding more languages implies simply adding a shell script. |
|
@dmackdev I think it would be nice if we didn't use I like the doc tests approach in rust better where |
|
I just added support for a bunch more languages in #255. Closing this as the bulk of the work is done. |
@mfontanini I was wonder if I could actually run python in the bash script for exec.
So here is what i came up with!
This is very much successful!
The output goes like-
It is amazing!
Now I would like to contribute based on this idea to the demo.md
And if we could make this as-
Then it would be great!
The text was updated successfully, but these errors were encountered: