llvm-project VS Lark

Interesting! What is your take on TinyGo. How does the LLVM compiler compare to say something you are familiar with, i.e. gcc? Would it be comparable?

Locating this kind of bug usually starts innocently, by commenting out various places of your own code, then analyzing your program under a debugger only to find yourself doing git clone https://github.com/llvm/llvm-project a few hours later 😅

> Should I report it somewhere?

Please do. You can open an issue (Bugzilla has been deprecated) on LLVM's github repo: https://github.com/llvm/llvm-project

Here is what Clang thinks: https://github.com/llvm/llvm-project/blob/589b9df4e15131348b...

parens: ()

squares: []

braces: {}

basically a mixed of British and American English

Apple | Debugger Engineer | Full-time | Onsite | Cupertino

The LLDB team at Apple is looking for an engineer to work on the LLDB debugger. LLDB is a core part of Apple's developer tools, used internally to debug Apple's software stack and externally by millions of developers. You’ll be able to work on different levels of the stack: from supporting our existing and upcoming platforms to developing new features to make debugging even better. Most of your work will be open source, on llvm.org (http://llvm.org/) and github.com (http://github.com/) where you’ll collaborate with the LLVM and Swift community.

If you love working on low-level tools you should check out the details here: https://jobs.apple.com/en-us/details/200311412/debugger-engi...

% emcc -v emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.8-git clang version 15.0.0 (https://github.com/llvm/llvm-project.git 80ec0ebfdc5692a58e0832125f2c6a991df9d63f) Target: wasm32-unknown-emscripten Thread model: posix InstalledDir: /usr/local/Cellar/emscripten/3.1.8/libexec/llvm/bin

clang + lldb for getting work done

If you are trying out parsing in python, I would recommend giving [Lark](https://github.com/lark-parser/lark) a try. I have used it for smallish projects are its really easy to use especially with the Earley parser.

Both were open sourced under MIT license (there's no dependency to Beancount lib). The reason I don't use Beancount lib is that I want to handle things like comments and emac org syntax. It would be much easier and cleaner to build a Lark based parser and work on top of that. Since the product I build is SaaS and there's zero dependency to the Beancount core, there was actually no requirement for open sourcing them. But I really like the plantext accounting community and would like to give back as much as I can, so I open sourced them here.

For the AST, do you mean the grammar? There's a descriptive EBNF grammar. You could then use Antlr or lark to parse script files to get the AST.

From https://github.com/lark-parser/lark

There's also lark, which is used by a plethora of projects (I haven't used it, but I heard about PreQL on a podcast where they talk for a bit about what it's like to develop a new language in lark)

Chiefly among the changes, Lark 1.0 dropped Python 2 support, and instead now uses the full range of Python 3 features, including type annotations. The API has also been straightened out and made more congruous. A full list of the changes is available in the release notes: https://github.com/lark-parser/lark/releases/tag/1.0.0