4 ms·

Using LLVM is a little bit harder but gives you advantages like better debugging. Long term that pays off. If you only play around, using C is fine.

• MaxBarraclough 9y ago
  Vala seems to be doing ok targeting C. I'd hardly say it's just for toys.
  • humanrebar 9y ago
    How does Vala handle debugging info and compiler diagnostics? Do the end users have to analyze the emitted C when something goes wrong?
    • MaxBarraclough 9y ago
      Annoyingly Vala is extremely shy about the generated C, but I believe it uses #pragmas to map the generated C back to the Vala source. I've only dabbled in Vala, but apparently its "-g" flag lets you debug with GDB. https://wiki.gnome.org/Projects/Vala/Tutorial#Debugging https://wiki.gnome.org/Projects/Vala/Tutorial#Debugging
  • qznc 9y ago
    There certainly is a grey area. For example, there are esoteric architectures which LLVM does not support but a C compiler exists. Emitting C is probably easier than developing a few LLVM backends. Still, my simple opinion is: If you are serious, use LLVM. It is not that much harder than outputting C and has clear advantages like debug information.
    • MaxBarraclough 9y ago
      As I mention below, Vala debugging isn't the catastrophe you think: https://wiki.gnome.org/Projects/Vala/Tutorial#Debugging https://wiki.gnome.org/Projects/Vala/Tutorial#Debugging I believe it's based on #pragmas that tell the C compiler (and/or GDB, presumably) which line of which file to blame. Serious work has been done in Vala. It's not fair to dismiss the language as a quaint toy.
      • qznc 9y ago
        Preprocessor directives are not powerful enough [0], imho. [0] https://news.ycombinator.com/item?id=16197856 https://news.ycombinator.com/item?id=16197856
        • MaxBarraclough 9y ago
          That isn't an attribute of using C as an IR, it's an attribute of optimising compilers. The solution is to disable optimisation for debug builds, not to avoid C. From the gnome.org page: > The -g command line option tells the Vala compiler to include Vala source code line information in the compiled binary
  • mirekrusin 9y ago
    Nim does it as well, but in case of Vala it's a bit different case as it emits glib based code with GObject and friends - basically whole OO system with containers, event loop and what not. The idea of Vala is that if you're using glib then using Vala will generate glib code as if you'd write it by hand, but much easier. The rationale is much stronger to emit C as you can mix it with existing code etc.
• dom96 9y ago
  I've never had any trouble debugging Nim, which compiles to C. The Nim compiler adds #line directives so you can just use gdb/lldb[1]. Can you elaborate on what debugging advantages LLVM brings? 1 - https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#using-gdb-lldb https://nim-lang.org/blog/2017/10/02/documenting-profiling-a...
  • qznc 9y ago
    Does Nim optimize anything on the way to C? That usually destroys useful information. I can give you an example from C compilers. Consider a simple loop: int a[] = ...; for (int i=0; i<max; i++) { print(a[i]); } Something fishy is printed, so I run it in my debugger, break at some point, and print "i". Gdb can usually do that. Now think about the optimizations a compiler probably did: While the index is incremented by 1, we actually step 4 bytes further due to the int array, so the compiler does i+=4 instead to avoid the multiply by 4 instruction. While i starts at 0, we can instead use the "a" pointer and avoid to add an offset at every loop iteration. The code might actually look like this: int *a = ... int end = a + max*4; for (char* x=a; x < end; x+=4) { print(x); } How can gdb print "i"? The trick is DWARF [0], basically the compiler inserts the information: If you want to print i here, then compute it by i=(x-a)/4. tldr: #line directives are not enough [0] https://en.wikipedia.org/wiki/DWARF https://en.wikipedia.org/wiki/DWARF