Interactive C environments were popular for a while. I have collected information on several at the Computer History Museum. I actually have even more stuff that I never got around to uploading.
You unfortunately need to make an account to see the pages. It was heavily attacked at one time and that was the admin's solution.
One of the biggest problem with these repl for complied languages is that they panic as soon as you rerun a command. `cling` integrates with Jupyter notebook too but as soon as you rerun a declaration of a variable, everything collapse and you have to reset the kernel. Maybe I didn’t dig deep enough and there is a way around this but if not, this is quite painful to deal with and a deal breaker.
One cool trick for C REPLs is to grep the man page directory to automate those pesky #include lines, e.g. https://gist.github.com/jart/5d0934d26b52f38cad36 Another trick is to build with STABS and use objdump -g.
This is really cool, nice work. I especially like the bit about putting a REPL statement in a source file to have it drop into bic. Seems like a quick and dirty way to debug without having to fire up gdb and such. Somewhere in between print statements and full on debugging.
> Dependency-free so that the runtime library (which is written in pure C) can be embedded in any application
What does dependency-free mean? I mean, it does depend on 128 crates. Do we typically not count those?
By the way, I did `cargo build` and it failed at `#include "utf8proc.c"`. I have `libutf8proc` installed. Changing `.c` to `.h` solved it. It went past that part, only to get:
- error: couldn't read cli/src/../../lib/binding_web/tree-sitter.js: No such file or directory (os error 2)
- error: couldn't read cli/src/../../lib/binding_web/tree-sitter.wasm: No such file or directory (os error 2)
Technically, you should be able to just call exit(1) because of the C's support for "implicit function declarations".
With no prior exit() declaration, the C compiler would assume that "exit" is "int exit()", spit out the code to push whatever arguments are passed to it down the stack and then just call the damn thing. So, magically, it will all just work. Requires an older compiler though, C89 the latest.
Modern GCC and Clang still support implicit functions. They just complain about it by default. (Mostly for reasons that shouldn't be entirely relevant to modern x86.)
One of the biggest problem with these repl for complied languages is that they panic as soon as you rerun a command. `cling` integrates with Jupyter notebook too but as soon as you rerun a declaration of a variable, everything collapse and you have to reset the kernel. Maybe I didn’t dig deep enough and there is a way around this but if not, this is quite painful to deal with and a deal breaker.
Interactive C environments were popular for a while. I have collected information on several at the Computer History Museum. I actually have even more stuff that I never got around to uploading.
You unfortunately need to make an account to see the pages. It was heavily attacked at one time and that was the admin's solution.
Interactive C Environments http://www.softwarepreservation.org/projects/interactive_c
Reminds me of CERN’s ROOT which has C/C++ interpreter https://root.cern.ch/
Their new repl is called cling: https://github.com/root-project/cling (They had an old one called C-INT or something like that).
One of the biggest problem with these repl for complied languages is that they panic as soon as you rerun a command. `cling` integrates with Jupyter notebook too but as soon as you rerun a declaration of a variable, everything collapse and you have to reset the kernel. Maybe I didn’t dig deep enough and there is a way around this but if not, this is quite painful to deal with and a deal breaker.
So repeating something like 'int i = 42;' causes problems?
Huh, I didn't know about that tool. Looking through the docs this looks impressive, especially since it can do C++ too.
One cool trick for C REPLs is to grep the man page directory to automate those pesky #include lines, e.g. https://gist.github.com/jart/5d0934d26b52f38cad36 Another trick is to build with STABS and use objdump -g.
This is really cool, nice work. I especially like the bit about putting a REPL statement in a source file to have it drop into bic. Seems like a quick and dirty way to debug without having to fire up gdb and such. Somewhere in between print statements and full on debugging.
Thanks for sharing.
I often looked for this and failed to find something that I could easily use. So I'm delighted to see this as a on/off C amateur and learner.
Thanks! It's still a work in progress but should hopefully help people to get to grips with C.
In the late 80s there was a product called C-Terp, which I loved!
Here's a link to a brief description:
https://books.google.com/books?id=fHghpJa3va4C&lpg=PA167&ots...
And, yes, I paid the $295 for it.
It lacks the syntax highlight. They could have used tree-sitter[1] for parsing, then the online highlight would be easier to implement.
[1] https://github.com/tree-sitter/tree-sitter
Agreed, syntax highlighting would be great. I was thinking about something akin to fish's syntax highlighting and completion with the REPL.
I'll take a look at tree-sitter. If I get syntax highlighting for free then I'll take that!
> Dependency-free so that the runtime library (which is written in pure C) can be embedded in any application
What does dependency-free mean? I mean, it does depend on 128 crates. Do we typically not count those?
By the way, I did `cargo build` and it failed at `#include "utf8proc.c"`. I have `libutf8proc` installed. Changing `.c` to `.h` solved it. It went past that part, only to get:
- error: couldn't read cli/src/../../lib/binding_web/tree-sitter.js: No such file or directory (os error 2)
- error: couldn't read cli/src/../../lib/binding_web/tree-sitter.wasm: No such file or directory (os error 2)
The generator isn't dependency free, the parser it generates is.
perhaps you meant to include https://github.com/tree-sitter/tree-sitter as reference.
Oh, yes, clipboard mistake, thanks for the correction!
I love that you have to #include how to exit :)
Technically, you should be able to just call exit(1) because of the C's support for "implicit function declarations".
With no prior exit() declaration, the C compiler would assume that "exit" is "int exit()", spit out the code to push whatever arguments are passed to it down the stack and then just call the damn thing. So, magically, it will all just work. Requires an older compiler though, C89 the latest.
Modern GCC and Clang still support implicit functions. They just complain about it by default. (Mostly for reasons that shouldn't be entirely relevant to modern x86.)
And people think exiting vim is hard!
I suppose you could always quit abruptly, though...
Why is fputs returning 1?
1 is a non-negative number. fputs() return nonnegative numbers on success...
Ah yeah true, looked at the wrong part of a man page.
an integration with jupyter would be nice.
One of the biggest problem with these repl for complied languages is that they panic as soon as you rerun a command. `cling` integrates with Jupyter notebook too but as soon as you rerun a declaration of a variable, everything collapse and you have to reset the kernel. Maybe I didn’t dig deep enough and there is a way around this but if not, this is quite painful to deal with and a deal breaker.