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.
Show HN: Bic – a C interpreter and API explorer
21–28 of 28 posts
Re: Show HN: Bic – a C interpreter and API explorer
#22It 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
> 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)
Re: Show HN: Bic – a C interpreter and API explorer
#23It 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
perhaps you meant to include https://github.com/tree-sitter/tree-sitter as reference.
Oh, yes, clipboard mistake, thanks for the correction!
Re: Show HN: Bic – a C interpreter and API explorer
#24It 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
> 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/…
The generator isn't dependency free, the parser it generates is.
Re: Show HN: Bic – a C interpreter and API explorer
#25Reminds me of CERN’s ROOT which has C/C++ interpreter https://root.cern.ch/
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?
Re: Show HN: Bic – a C interpreter and API explorer
#26I 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.
Re: Show HN: Bic – a C interpreter and API explorer
#27I 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.)
Re: Show HN: Bic – a C interpreter and API explorer
#28One 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.